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(57) Abstract 

Various methods for synchronizing incompatible databases using a history file containing records representing records of one of the 
databases at the time of a previous synchronization. A method allows synchronizing databases in which different techniques are used for 
storing a recurring event A database in which the recurring event is, for example, stored as a single recurring rec rd can be synchronized 
with a database in which the same recurring event is stored as a series of individual records. Another method permits comparing records 
from two different databases where at least one of the databases is subject to rules of data value to which the other database is not subject 
The rules of data value are applied to the comparison so that their effect is neutralized and a meaningful comparison can be made. The rules 
of data value of one database can be used to change copies of the records of the other database. A further method allows synchronizing 
at least a first and a second database each containing dated records such as events, where the records of the first and second databases are 
synchronized across a narrow date range narrower than the date range of the records of at least one of the databases. Another method allows 
synchronizing two or more databases with a single database. In that case, for example, synchronized rec rds are tagged with database 
identifying codes which indicated the database from which the records originated. 
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SYNCHRONIZATION OF DATABASES 

Background 
This invention relates to synchronizing 
5 incompatible databases. 

Databases are collections of data entries which 
are organized, stored, and manipulated in a manner 
specified by applications known as database managers 
(hereinafter also referred to as "Applications"). The 

10 manner in which database entries are organized in a 
database is known as the data structure. There are 
generally two types of database managers. First are 
general purpose database managers in which the user 
determines (usually at the outset, but subject to future 

15 revisions) what the data structure is. These 

Applications often have their own programming language 
and provide great flexibility to the user. Second are 
special purpose database managers that are specifically 
designed to create and manage a database having a preset 

20 data structure. Examples of these special purpose 
database managers are various scheduling, diary, and 
contact manager Applications for desktop and handheld 
computers. Database managers organize the information in 
a database into records, with each record made up of 

25 fields* Fields and records of a database may have many 
different characteristics depending on the database 
manager's purpose and utility. 

Databases can be said to be incompatible with one 
another when the data structure of one is not the same as 

30 the data structure of another, even though some of the 
cont nt f the records is substantially the sam . F r 
example, n database may store names and addresses in 
the f llowing fi Ids: FIRST NAME, LAST_NAME, and 
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ADDRESS • Anoth r database may, however, store the sam 
information with the following structure: NAME, 
STREET_NO • , STREET_NAME, CITY_STATE , and ZIP. Although 
the content of the records is intended to contain the 
5 same kind of information, the organization of that 
information is completely different* 

It is often the case that users of incompatible 
databases want to be able to synchronize the databases. 
For example, in the context of scheduling and contact 

10 manager Applications, a person might use one Application 
on the desktop computer at work while another on his 
handheld computer or his laptop computer at home. It is 
desirable for many of these users to be able to 
synchronize the entries on one with entries on another. 

15 However, the incompatibility of the two databases creates 
many problems that need to be solved for successful 
synchronization. The U.S. patent and copending patent 
application of the assignee hereof, Intel liLink Corp., of 
Nashua, New Hampshire (U.S. Patent No. 5,392,390; U.S. 

20 Application, Serial No. 08/371,194, filed on January 11, 
1995, incorporated by reference herein) show two methods 
for synchronizing incompatible databases and solving some 
of the problems arising from incompatibility of 
databases. However, other problems remain. 

25 One kind of incompatibility is when one database 

manager uses recurring records. Recurring records are 
single records which contain information which indicates 
that the records actually represent multiple records 
sharing some common information. Many scheduling 

30 Applications, for example, permit as a single record an 
event which occurs regularly over a period of time. 
Instances of such entries are biweekly committee meetings 
or we kly staff lunches. Other scheduling Applications 
do not us th s typ s of records. A user has to cr ate 
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equivalent ntries by cr a ting a separat record for each 
instance f these recurring events. 

Various problems arise when synchronizing these 
types of records. Let us consider a situation when 
5 Application A uses recurring records while Application B 
does not* A synchronizing application must be able to 
create multiple entries for B for each recurring entry in 
A. It also must be able to identify some of the records 
in database B as instances of recurring records in 

10 database A. Also, many Applications which allow 

recurring records also permit revision and editing of 
single instances of recurring records without affecting 
the master recurring record. Moreover, single instances 
of a recurring event in Application B may be changed or 

15 deleted. The recurring master may also be changed which 
has the effect of changing all instances. These changes 
make it harder to identify multiple entries in database B 
as instances of a recurring record in database A. 
Moreover, synchronization must take these changes into 

20 account when updating records in one or the other 
database. 

Another kind of incompatibility arises in the case 
of database managers which impose restrictions and rules 
on the content of records. For example, the length of 

25 text entered by a user into a field may be limited (e.g. 
to save storage space) or the values permitted may be 
limited (e.g. to impose psychological discipline, as in 
limiting priority values in To Do lists to 3). The 
Application may also require that all text be UPPERCASE. 

30 Other limitations may be more complicated, in the form of 
complex rules and requirements. In Microsoft® Schedule*, 
for example, Tasks records have four fields called 
StartDate, EndDate, AlarmDate, and AlarmFlag. The 
contents f these fi Ids must follow a set of rules. If 

35 StartDate and EndDate are both blank, AlarmDate must be 
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blank and AlarmFlag must be set to FALSE, because 
Schedule* do s n t allow alarms for undated Tasks. If 
StartDate is not blank, the EndDate should not be blank 
either. Because of these rules, issues arise with 
5 respect to how records from these incompatible databases 
compare . 

Another kind of incompatibility arises in the case 
of databases which run on computer systems with very 
limited storage capacity, such as handheld computers. It 

10 is often desirable to synchronize the databases on these 
devices with databases on larger computers such as 
desktop computers which have much higher storage 
capacity. However, a straight synchronization between 
the Applications on the two devices may result in storage 

15 capacity of the smaller devices being mostly consumed 
with the records from the larger device, rendering the 
smaller device inoperable. 

In one general aspect, the invention provides a 
20 technique for synchronizing databases in which different 
techniques are used for storing a recurring event. A 
database in which the recurring event is, for example, 
stored as a single recurring record can be synchronized 
with a database in which the same recurring event is 
25 stored as a series of individual records. The individual 
records are processed to form a synthetic recurring 
record representing the set of individual records, and 
synchronization decisions are based on a comparison of 
the synthetic record to the recurring record of the other 
30 database. Following synchronization, the synthetic 

rec rd can be "fanned" back into the individual records 
to update the database containing individual records, and 
the updated r curring record can b written back to the 
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oth r databas . In this way, the invention av ids the 
problems ncount red with prior methods, in which 
synchronization resulted in a recurring record being 
transformed into a series of individual records. 
5 In another general aspect, the invention features 

a computer implemented method of synchronizing at least a 
first and a second database, wherein the manner of 
storing a set of recurring instances differs between the 
first and second databases, and at least the first 

10 database uses a recurring record to store the set of 
recurring instances. A plurality of instances in the 
second database are processed to generate a synthetic 
recurring record representing recurring instances in the 
second database, the synthetic recurring record of the 

15 second database is compared to a recurring record of the 
first database, and synchronization is completed based on 
the outcome of the comparison. 

Preferred embodiments of these aspects of the 
invention may include one or more of the following 

20 features: Completing synchronization may include adding, 
modifying, or deleting the synthetic recurring record or 
the recurring record. Following synchronization, the 
synthetic recurring record may be fanned back into a 
plurality of single instances. The set of recurring 

25 instances may be stored in the second database as a 
plurality of single instances. The set of recurring 
instances may be stored in the second database as a 
recurring record having a different record structure than 
the recurring record of the first database. A history 

30 file may be stored containing a record representative of 
the presence of a recurring record or a synthetic 
recurring record in past synchronizations. 

In y t another general aspect, the invention 
allows comparison of r cords from two different databases 

35 where at least one of the databases is subj ct to rules 
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of data value to which the other database is not subject. 
The rules of data value of ne database are used to 
change copies of the records of the other database so 
that a meaningful comparison can be made. 
5 The invention features a computer implemented 

method of synchronizing records of first and second 
databases, wherein at least one field of records of the 
first database is subject to a first rule of data value 
to which the corresponding field of records of the second 

10 database is not subject. The first rule of data value of 
a field of the first database is used to modify copies of 
the content of corresponding fields of records of the 
second database. Thereafter, the content of the modified 
copies is compared to the content of the corresponding 

15 field of the first database, and synchronization actions 
are taken based on the outcome of the comparison. 

In preferred embodiments of this aspect of the 
invention, at least one field of records of the second 
database is subject to a second rule of data value to 

20 which the corresponding field of records of the second 
database is not subject, and the second rule of data 
value is used to modify copies of the content of 
corresponding fields of records of the first database; 
and the content of modified copies of the content of the 

25 first database is compared to modified copies of the 
content of the second database. 

In another general aspect, the invention may take 
into account rules of data value at the time of 
comparison. For example, two text fields may be compared 

30 only up to the character limit of one of them. 

In one other general aspect, the invention 
provides a method of synchronizing multiple databases of 
different Applications. A database's record, when 
written in another database may be tagged with a uniqu 

35 mark identifying the sourc of th record. Th se tags 
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may be us d to f ilt r out only those r cords which should 
be synchronized. Th tags may be attached when th 
records are unloaded to the databases. 

In yet another general aspect, the invention 
5 solves the difficulty of synchronizing databases in which 
events are maintained across different date ranges. A 
date range is set for which synchronization will take 
place. Records falling outside of the date range are not 
synchronized. The date range of the prior 

10 synchronization is stored, and a current synchronization 
is performed across the combination of the current and 
prior date ranges. The problems of synchronization 
software attempting to fill a smaller capacity device 
with events across a wide date range that can only 

15 practically be stored on a larger capacity device are 
avoided. 

In this aspect, the invention features a computer 
implemented method of synchronizing at least a first and 
a second database each containing dated records such as 

20 events, wherein the records of the first database extend 
across a narrow date range narrower than the date range 
of the records of the second database. A prior 
synchronization is performed across a prior date range 
set using the date of the prior synchronization and the 

25 narrow date range. The date range of the prior 

synchronization is stored, along with the history file 
containing information representative of the content of 
the databases following the prior synchronization. When 
a current synchronization is performed, it is performed 

30 across a date range that combines the prior date range 
with a current date range set using the date of the 
current synchronization and the narrow date range. 

Th invention may be implemented in hardware r 
software, or a combination of both. Preferably, the 

35 technique is implemented in computer programs executing 
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on programmable computers that ach include a processor, 
a storage medium readable by the processor (including 
volatile and non-volatile memory and/ or storage 
elements), at least one input device, and at least one 
5 output device* Program code is applied to data entered 
using the input device to perform the functions described 
above and to generate output information. The output 
information is applied to one or more output devices. 

Each program is preferably implemented in a high 

10 level procedural or object oriented programming language 
to communicate with a computer system. However, the 
programs can be implemented in assembly or machine 
language, if desired. In any case, the language may be a 
compiled or interpreted language. 

15 Each such computer program is preferably stored on 

a storage medium or device (e.g., ROM or magnetic 
diskette) that is readable by a general or special 
purpose programmable computer for configuring and 
operating the computer when the storage medium or device 

20 is read by the computer to perform the procedures 
described in this document. The system may also be 
considered to be implemented as a computer-readable 
storage medium, configured with a computer program, where 
the storage medium so configured causes a computer to 

25 operate in a specific and predefined manner. 

Other features and advantages of the invention 
will become apparent from the following description of 
preferred embodiments, including the drawings, and from 
the claims. 



30 Brief Description of the Drawing 

Figure 1 is a schematic drawing of the various 
modules constituting th preferred embodiment. 

Figur 2 is a representation of th Workspace data 

array. 
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Figure 3 is the pseudocode for th Translation 
Engine Control Module. 

Figure 4 is the pseudocode for generating the 
parameter Table. 
5 Figure 5 is the pseudocode for fanning a recurring 

record. 

Figure 6 is the pseudocode for the Synchronizer 
loading the History File. 

Figure 7 is the pseudocode for matching key fields 
10 (Key_Field_Match) . 

Figure 8 is the pseudocode for loading records of 
B_Database into Workspace. 

Figure 9 is the pseudocode for A_Sanitization of 
B_Database records in Workspace. 
15 Figure 10 is the Pseudocode for a specific example 

of a rule of data value used for sanitization. 

Figure 11 is the pseudocode for orientation 
analysis • 

Figure 12 is the pseudocode for Conflict Analysis 
20 And Resolution (CAAR) . 

Figure 13 is the pseudocode for analyzing unique 
ID bearing Fanned Instance Groups (FIGs) . 

Figure 14 is the pseudocode for expanding CIGs 
created from unique ID bearing records. 
25 Figure 15 is the pseudocode for finding weak 

matches for a record. 

Figure 16 is the pseudocode for finding matches 
between recurring items and non_unique ID bearing 
instances . 

30 Figure 17 is the pseudocode for completing Same 

Key Group (SKG) analysis. 

Figure 18 is the pseudocode for setting the 
Maximum_CIG_Size for ev ry CIG analyz d in Figure 17. 

Figur 19 is the pseud code for setting CIG_ Types. 
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Figure 20 is the User Interfac for conflict 
resolution wh n the Notify option is sel cted. 

Figure 21 is the pseudocode for merging exclusion 

lists. 

5 Figure 22 is a look up table used by the function 

in Fig. 21* 

Figure 23 is a look up table used by the function 
in Fig. 21. 

Figure 24 is a look up table used by the function 

10 in Fig. 21. 

Figure 25 is a pseudocode for unloading records 
from Workspace to a non-rebuild-all database. 

Figure 26 is the look up table for determining 
unloading outcome results. 
15 Figure 27 is the pseudocode for fanning recurring 

records of A-Database for unloading. 

Figure 28 is the pseudocode for unloading the 
History File. 

Figure 29 is a table showing cases for fanning 
20 Recurring Masters into own database. 

Description 

Fig. 1 shows the relationship between the various 
modules of the preferred embodiment. Translation Engine 
1 comprises Control Module 2 and Parameters Table 

25 Generator 3. Control Module 2 is responsible for 
controlling the synchronizing process by instructing 
various modules to perform specific tasks on the records 
of the two databases being synchronized. The steps taken 
by this module are demonstrated in Fig. 3. The 

30 Parameters Table Generator 3 is responsible for creating 
a Parameter_Table 4 which is used by all other modules 
f r synchr nizing th databases. D tails of the 
Parameter_Table are describ d in more d tail below. The 
Synchronizer 15 has primary responsibility for carrying 



WO 98/24018 



PCT/US97/20660 



- 11 - 

out the core synchronizing functions. It is a table- 
driven cod which is capabl of synchronizing various 
types of databases whose characteristics are provided in 
the ParameterJTable 4. The Synchronizer creates and uses 
5 the Workspace 16 , which is a temporary data array used 
during the synchronization process* 

A Translator 5 (A_Translator) is assigned to the 
A_database 13 and another Translator 9 (B_Translator) to 
the B_database 14. Each of the database Translators 5 

10 and 9 comprises three modules: Reader modules 6 and 10 
(A_Reader and B_Reader) , which read the data from the 
databases 13 and 14; Unloader modules 8 and 12 
(A_Unloader and B_Unloader) , which analyze and unload 
records from the Workspace into the databases 13 and 14; 

15 and Sanitizing modules 7 and 11 (A_Sanitizer and 

B_Sanitizer) , which analyze the records of the other 
database loaded into the Workspace and modify them 
according to rules of data value of its own database. In 
the preferred embodiment, the modules of the 

20 AJTranslator 5 are designed specifically for interacting 
with the A_database 13 and the A_Application 17. Their 
design is specifically based on the record and field 
structures and the rules of data value imposed on them by 
the A_Application, the Application Program Interface 

25 (API) requirements and limitations of the A_Application 
and other characteristics of A_Database and 
^Application. The same is true of the modules of 
B_ Translator 9. These Translators are not able to 
interact with any other databases or Applications. They 

30 are only aware of the characteristics of the database and 
the Application for which they have been designed. 
Therefore, in the preferred embodiment, when the user 
ch oses two Applications for synchronizati n, the 
Translation Engine chooses the two Trans lat rs which are 

35 able t interact with those Applications. In an 
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alt mat emb diment, the translator can be designed as a 
table-driven code, where a general Translator is able to 
interact with a variety of Applications and databases 
based on the parameters supplied by the Translation 
5 Engine 1. 

Referring to Figs. 1, 2 and 3, the synchronization 
process is as follows. The Parameter_Table 4 is 
generated by the Parameter Table Generator 3. The 
Synchronizer 15 then creates the Workspace 16 data array 

10 and loads the History File 19 into the Workspace 16. The 
B_Reader module 11 of the B_Translator reads the 
B_database records and sends them to the Synchronizer for 
writing into the Workspace. Following the loading of 
B_Database records, the A_Sanitizer module 8 of the 

15 AJTranslator 5 sanitizes the B_Records in the Workspace. 
The A_Reader module 7 of the A_Translator 5 then reads 
the AJDatabase records and sends them to the Synchronizer 
16 for writing into the Workspace. The B_Sanitizer 
module 12 of the B_Translator 9 then sanitizes the 

20 A_Records in the Workspace. The Synchronizer then 

performs the Conflict Analysis and Resolution (CAAR) on 
the records in Workspace. At the end of this analysis 
the user is asked whether he/she would like to proceed 
with updating the A_ and B_dat abases. If so, the 

25 B_Unloader module of the B_Translator unloads the 

appropriate records into the B_database. The A_Unloader 
module 6 then performs the same task for the A_Database. 
Finally, the Synchronizer creates a new History File 19. 
Fig. 3 is the pseudocode for the preferred 

30 embodiment of the Control Module 2 of the Translation 

Engine 1. Control Module 2 first instructs the Parameter 
Table Generator 3 of the Translation Engine 1 to create 
th Param terJTabl (Step 100) . Fig. 4 is th pseud code 
for the pr f err d embodiment of the Paramet r Tabl 

35 6 n rat r m dule 3. The user is first asked to ch se 
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vh ther t us a previously chosen and stored set £ 
preferences or to nter a n v s t of preferences (St p 
150) . Steps 151-165 show the steps in which the user 
inputs his/her new preferences. In step 152, the user 
5 chooses whether to perform a synchronization from scratch 
or an incremental synchronization. In a synchronization 
from scratch, synchronization is performed as if this was 
the first time the two databases were being synchronized. 
In an incremental synchronization, the History File from 

10 the previous file is used to assist with synchronization. 
The user will likely choose incremental synchronization 
if there has been a prior synchronization, but the user 
may choose to synchronize from scratch where the user 
would like to start with a clean slate (perhaps due to 

15 significant change in the nature of the data in the 

databases) . The user then selects the two Applications 
and related databases (A_Database and B_Dat abase) to be 
synchronized (step 153). The user then chooses (step 
154) whether the Synchronizer should use the default 

20 field mapping for those two databases during 

synchronization or the user will modify the field 
mapping. Field mapping is generally described in U.S. 
Patent No. 5,392,390 (incorporated by reference). In 
accordance with the user's preferences, the Parameter 

25 Table Generator then stores the appropriate A_Database to 
B_Database fields map (A-+B_Map) and B__Database to 
A_Database fields map (B->A_Map) in the Parameter_Table 
(Steps 155-158 and 159-163, accordingly). 

If in step 150 the user selected to use previously 

30 chosen and stored set of preferences (steps 166-171) , 
those preferences are loaded and stored in the 
ParameterJTable (steps 169-170) . 

In case of date b aring records such as 
appointments and ToDo lists, the user enters th date 

35 range for which the user wants the records to be 
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synchronized (step 172) . The preferred embodiment allows 
th user to use relative date ranges 

(Automatic_Date_Range) (substeps 171 (a) and (b) ) . For 
example, the user can select the date range to be 30 days 
5 into the past from today's date and 60 days into the 
future from today's date. The Parameter Table Generator 
3 then calculates and stores in the Parameter_Table the 
Start_Current_Date_Range and End_Current_Date_Range 
values, the two variables indicating the starting point 

10 and the ending point of the date range for the current 
synchronization session (step 173-174). 

In steps 174 and 175, various parameters 
identifying the characteristics of the A_Database and 
Application and B_Database and Application are loaded 

15 from a database (not shown) holding such data for 

different Applications. These are in turn stored in the 
Parameter_Table. One of the sets of parameters loaded 
and stored in the ParameterJTable is the FieldJList for 
the two databases. The Field_List_A and Field_List_B 

20 contain the following information about each field in the 
data structure of the two databases: 

1. Field name. 

2. Field Type. 

3. Field Limitations* 
25 4. No_Reconcile Flag. 

6. Key_Field Flag. 

7. Mapped_Field Flag. 

Field name is the name given to the field which the 
Translator for this Application uses. This name may also 

30 be the name used by the Application. Field Type 

identifies to the Synchronizer 15 the nature of the data 
in a field, e.g., Data, Time, Boolean, Text, Number, or 
Binary. The Field Name does not supply this informati n 
to the Synchroniz r. Field Limitati ns identifies the 

35 various limitations th database manager imp ses on the 
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cont nts of a field. Th se limitations include: maximum 
length of text fields, whether th text field must b in 
upper-case, range of permissible values (for example, in 
ToDo records priority field, the range of permissible 
5 values may be limited from 1 to 4), and whether a single 
line or multiple line field. 

No_Reconcile flag indicates whether a field is a 
No_Reconcile field, meaning that it will not be used to 
match records nor will it be synchronized although it 

10 will be mapped and possibly used in synchronization. 

Almost all fields will not be designated as No_Reconcile. 
However, sometimes it is necessary to do so. Key_Field 
flag indicates that a field should be considered as a key 
field by the Synchronizer 15. 

15 Key fields are used by the Synchronizer in various 

stages of synchronization as will be discussed in detail 
below. The decision of identifying certain fields as key 
is based on examining the various Applications to be 
synchronized, their data structure, and the purpose for 

20 which the database is used. Such examination reveals 
which fields would best function as key fields for 
synchronization. For example, for an address book 
database, the lastname, first name, and company name field 
may be chosen as key fields. For Appointments, the date 

25 field and the description field may be chosen as key 
fields. 

Mapped_Field flag indicates whether a field is 
mapped at all* The Synchronizer uses this flag to 
determine whether it should use the A-+B_Map or B-»A_Map to 
30 map this field. Unlike a NoJReconcile field, an unmapped 
field will not be carried along through the 
synchronization • 

Another set of param ters in the Param ter_Table 
identify the Translator Modules 13, 14 for the two 
35 Applicati ns which the user has selected. Because each 
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Application is assigned its own Translator, it is 
necessary to identify to the Command Module and the 
Synchronizer which Translators should be used. 

In step 102 of Fig. 1, the Translation Engine 
5 instructs the Synchronizer to load the History File. 
History File is the file which was saved at the end of 
last synchronization. It contains the history of the 
previous synchronization which is necessary for use with 
the current synchronization in case of Incremental 

10 Synchronization. Records from the A_Database and 
BJDatabase are analyzed against the records of the 
history file to determine the changes, additions, and 
deletions in each of two databases since last 
synchronization and whether additions, deletions, or 

15 updates need to be done to the records of the databases. 
Referring to Fig. 5, in steps 200-201, the Synchronizer 
finds the appropriate History file to be loaded. If 
Synchronization_from_Scratch flag is set, the History 
File is deleted (step 203). If no History File is found, 

20 the synchronization will proceed as if it was a 

synchronization from scratch (step 204). If the. Field 
Lists stored in the History File are not the same as the 
current Field Lists in the Parameter_Table , or the 
mapping information is not the same, the synchronization 

25 will proceed as synchronization from scratch because the 
differences indicate that the History File records will 
not properly match the database records (steps 206-209) • 
In step 210, the Synchronizer uses the Field_List 
for database B to create the Workspace 16. It is a large 

30 record array which the Synchronizer uses during 

synchronization. Referring to Fig. 2, Workspace 16 
consist of two sections. First, the Synchronizer uses 
the Fi Id List for th B_Database to mak a record array 
21 which has all the characteristics of the B_Databas 

35 r cord structur . In addition, in each record in the 
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Workspac , certain internal fields ar added. On field 
is ^subtype containing Origin Tags. Two other fi lds / 
called Rep_Basic and Rep_Excl, are included for all 
Appointment and ToDo Sections. The Rep_Basic field gives 
5 a full description of the recurrence pattern of a 

recurring record. It includes the following parameters: 

1 . Basic_Repeat_Type 

2 . Frequency 

3 . StopDate 

10 4. other parameters 

5. Rep_Excl 

Basic_Repeat_Type contains the variable which 
indicates whether the recurring record is a daily, 
weekly, monthly (same date each month) , monthly by 

15 position (e.g., 3rd Friday of each month), yearly (e.g., 
July 4th each year), yearly by Position (e.g., 3rd Friday 
of September each year) , quarterly, etc. This variable 
is set to No_Repeat for non-recurring records. 

Frequency indicates whether the pattern is, for 

20 example, for every week, every other week, etc. 

StartDate and StopDate show the first date and last date 
in the pattern. Some other parameters in the Rep_Basic 
include, for example, a list of days to be included for 
the pattern (e.g. I plan to hold a weekly staff meeting 

25 every Thursday starting November 15, 1997.) 

Rep_Excl is the exclusion list. It is a list of 
dates which at some point belonged to the recurring 
record, but have since been deleted or modified and no 
longer are an event represented by the recurring record. 

30 Since some databases do not provide for recurring 

types of records, the synchronization process sometimes 
must create single records for each of the instances of a 
recurring record for those databases. For example, for a 
recurring lunch every Thursday, the synchronization must 

35 produce a single record for ach Thursday in such a 
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database* This is acc mplish d by the pr cess f fanning 
which us s R p_Basic. Each of those instances is called 
a fanned instance. Pig. 6 sets out the preferred 
embodiment of the process of fanning a record. 
5 Fanning of recurring records also takes into 

account another set of considerations regarding date 
range limitations and usefulness of instances to the 
user. 

First, fanning is limited to the applicable date 

10 range. Second, the number of fanned instances is limited. 
When synchronizing Databases A and B, the preferred 
embodiment permits different sets of limits on fanned 
instances to be established for each Database. This, for 
example, assists with managing storage capacity of a 

15 memory-constrained handheld device when being 
synchronized with a database on a desktop PC. 

If the current Date Range is large enough to 
accommodate more than the maximum number of instances 
which might be generated, those instances will be chosen 

20 which are likely to be most useful to the user. In the 
preferred embodiment, it is assumed that future instances 
are always more useful than past instances, that near 
future instances are more useful than distant future 
instances, and that recent past instances are more useful 

25 than distant past instances. Therefore, based on these 
assumptions, a fanning date range is calculated (Fig. 6, 
step 236) • 

Referring to Fig. 2, in the second step of 
creating the Workspace, the Synchronizer establishes an 
30 Extended Index Array 20 which has an index entry 

associated with each entry in the record array. Each 
index contains the following variables: 

1. Next_In_CIG: 

2. Next_In_SKG: 
35 3. Next In FIG 
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4. K y_Field_Hash 

5 . A_ Unique_ID_Hash 

6 . B_Unique_ID_Hash 

7 . Non_Key_Field_Hash 
5 8 . Non_Date_Hash 

9 . Exclusion_List_Hash 

10. Start_Date&Time 

11 . End_Date&Time 

12. Various bit flags 

10 Next_In_CIG is a linkage word, pointing to next 

member of the same Corresponding Item Group (CIG) . A CIG 
is a group of records, one from each database and the 
History File, if applicable, which represent the same 
entry in each of the databases and the History File. 

15 There may be one, two or three records in a CIG. 

Next_In_SKG is a linkage word, pointing to next member of 
the Same Key Fields Group (SKG) . An SKG is a group of 
records having the same key fields. Next_In_ FIG is a 
linkage word, pointing to the next member of the Fanned 

20 Instances Group (FIG) • A FIG is the group of fanned 

instances which correspond to a single recurring record. 

Key_Field_Hash is hash of all Key_Fields. 
A_unique_ID_Hash is hash of unique ID, if any, assigned 
by A_Database. B_unique_ID_Hash is hash of unique ID, if 

25 any, assigned by B_Database. Non_Key_Field_Hash is hash 
of all Non-Key Match Field, a Match Field being any 
mapped field which is not flagged as No_Reconcile. 
Non_Date_Hash is hash of all Non-Date Non-Key Match 
Fields. Exclusion_List_Hash is hash of recurring 

30 record's exclusion list. 

Start_Date&Time and End_Date&Time are used for 
Appointment and ToDo type record only, indicating the 
start and end dat and time of th record. They are used 
t speed up comparing functions throughout the 

35 synchr nization. 
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Hash values are also us d to speed up the process of 
comparis n. The preferred embodiment uses integer 
hashes. Hash value computation takes into account 
certain rules of data value for fields, as will be 
5 described in more detail below. 

In the preferred embodiment, the record array 21 
is stored on magnetic disk of a computer whereas the 
Extended Index 20 is held resident in memory. The 
Extended Indexes have record pointer fields which point 

10 to each of the records on the disk file. 

The Control Module 2 now instructs the 
synchronizer to load the History File into the Workspace 
(Fig. 3, step 102). Referring to Fig. 6, the 
synchronizer loads the records beginning in first 

15 available spot in the Workspace (step 211) . The 

Synchronizer then performs an analysis on each of the 
records and resets some of the values in the records 
(steps 212-228). In case of recurring records, if any 
of the instances is within the current date range, then 

20 the recurring record itself will be considered within the 
current date range (steps 217-227) . The 
synchronizer then builds SKGs by finding for each history 
record one record which has matching key fields and by 
placing that record in the SKG of the history record 

25 (step 215-216). Referring to Fig. 7, steps 250-258 

describe the Key_Field_Match function used for matching 
records for SKG. 

When comparing two records or two fields, in the 
preferred embodiment, the COMPARE function is used. The 

30 COMPARE function is intelligent comparison logic, which 
takes into account some of the differences between the 
rules of data value imposed by the A_Application and the 
B__Applicati n n th ir r sp ctiv databases. S me 
examples ar as follows. The COMPARE function is 

35 insensitive t upper and lower case letters if case 
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Applications require entries to be in all capital 1 tt r, 
the COMPARE function ignores the differences between 
upper and lowercase letters. The COMPARE function takes 
5 into account any text length limitations. For example, 
when comparing "App" in the A_Database and "Apple" in the 
B_Database, the COMPARE function takes into account that 
this field is limited to only 3 characters in the 
A_Database. It also takes into account limits on 

10 numerical value. For example, priority fields in the 
A_Application may be limited to only values up to 3, 
whereas in the B_Application there may not be any 
limitation. The COMPARE function would treat all values 
in B_records above 3 as 3. 

15 The COMPARE function may ignore various codes such 

as end of line characters. It may strip punctuation from 
some fields such as telephone numbers and trailing white 
space from text fields (i.e "Hello " is treated as 
"Hello") . It also considers field mapping. For example, 

20 if the only line that is mapped by the A-»BJMap is the 
first line of a field, then only that line is compared. 
When comparing appointment fields, because different 
databases handle alarm date and time differently when 
Alarmflag is false, the COMPARE function treats them as 

25 equal even though the values in them are not the same. 
It skips Alarm Date and Time, if the Alarm Flag is False. 
It also ignores exclusion lists when comparing recurring 
records. 

In an alternate embodiment, the COMPARE function 
30 may take into account more complicated rules for data 

value of the two Applications, such as the rules for data 
value imposed by Microsoft Schedule*, described above. 
Such a COMPARE function may be implemented as a table 
driven code, the table containing the rules imposed by 
35 the A_Application and the B_Application. Because th 
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COMPARE function has a sp cific comparis n logic and 
takes into account a number of rules, the hashing logic 
must also follow the same rules. It should be noted that 
the COMPARE function is used throughout the preferred 
5 embodiment for field comparisons. 

Now that the History File is loaded into the 
Workspace, the Control Module 2 instructs the 
B_Translator 13 to load the B_Database records (Fig. 3, 
step 103). Referring to Fig. 8, steps 300-308, the 

10 B_Reader module 11 of the B_Translator 13 loads each 
B_record which has the right Origin Tag, which will be 
explained in more detail below. 

The record must also be within the loading date 
range, which is a concatenation of the previous and 

15 current date ranges. The B_Translator sends these 

records to the Synchronizer which in turn stores them in 
the Workspace. When synchronizing with a date range 
limitation, all records which fall within either the 
previous or the current date ranges are loaded. The 

20 current date range is used during unloading to limit the 
unloading of the records to only those records which fall 
within the database's current date range. In an 
alternate embodiment of the invention, each database or 
Application can have its own date range for each 

25 synchronization. 

Most Applications or databases permit record- 
specific and field-specific updates to a Database. But 
some Applications or databases do not. Instead the 
Translator for these Application must re-create the whole 

30 database from scratch when unloading at the end of 
synchronization. These databases are identified as 
Rebuild_All databases. To accommodate this requirement 
all rec rds fr m such a database must be load d int the 
Workspac , so that th y can later be used to rebuild th 

35 whole databas . Thes databases rec rds, which w uld 
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otherwise have b en filter d ut by the date rang or the 
wrong origin tag filters, are instead marked with special 
flag bits as Out_Of_Range or Wrong_Section_Subtype. 
These records will be ignored during the synchronization 
5 process but will be written back unmodified into the 

database from which they came by the responsible Un loader 
module 6, 10. 

Control Module 2 next instructs the A_Translator 5 
to sanitize the B-records. Referring to Fig. 9, steps 

10 350-361, the A_Sanitizer module 8 of the AJTranslator 5 
is designed to take a record having the form of an 
A_Record and make it conform to the specific rules of 
data value imposed by the A_Application on records of the 
A_Database. A_Sanitizer is not aware which database's 

15 field and records it is making to conform to its own 
Application's format. It is only aware of the 
A_Applicat ion's field and record structure or data 
structure. Therefore, when it requests a field from the 
sanitizer using the A_Database field name, it is asking 

20 for fields having the A_Database data structure. The 
Synchronizer, in steps 375-387, therefore maps each 
record according to the B->A_Map. In turn, when the 
Synchronizer receives the fields from the A_SANITIZER, it 
waits until it assembles a whole record (by keeping the 

25 values in a cache) and then maps the record back into the 
B format using the A->B_Map. 

How a record or a field is sanitized in step 354 
and 357 depends on the rules of data value imposed by the 
^.Application. For example, all of the logic of 

30 intelligent comparison in the COMPARE function described 
above can be implemented by sanitization. However, 
sanitization is best suited for more complex or unique 
types of database rules for data value. For xampl , 
consider th Sch dule+ rules r garding alarm bearing 

35 Tasks r cords describ d above. Fig. 10 shows a 
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sanitizati n m thod for making records of incompatibl 
databas s c nf rm to the requirements of Schedule*. 
Without sanitization, when a Tasks record of a Schedule* 
database is compared to its corresponding record in 
5 another database, the Tasks record may be updated in 
fields which should be blank according to the Schedule* 
rules of data value. Such an update may possibly affect 
the proper operation of Schedule* after synchronization. 
Referring to Fig. 11, following sanitization of 

10 all B_Records into the Workspace, the Synchronizer sets 
the values for the Extended Index of each record based on 
the record's values (steps 451-459). Also if the records 
in the BJDatabase bear a unique ID, and matches for those 
unique IDs are found in the H_Records in the Workspace, 

15 the two records are joined in a CIG because they 
represent the same record in both History File and 
B__Database (step 462) • The record is also joined to an 
SK6 it may belong to (step 464). The loading of 
B_Records is now complete. 

20 The Control Module 2 of the Translation Engine 3 

now instructs the A_Translator 5 to load the records from 
the A_Database (step 105) . The loading process for the 
A_Records is the same as the loading process for the 
B_Dat abase, except for some differences arising from the 

25 fact that records in the Workspace are stored according 
to the B_Database data structure. Therefore, as the 
synchronizer 15 receives each A_record from the A_Reader 
module 7 of the A_Translator 5, the Synchronizer maps 
that record using the A-*B_Map before writing the record 

30 into the next available spot in the Workspace. Since the 
A_records are mapped into the B_Record format, when the 
B_Sanitizer is instructed by the Control Module 2 to 
begin sanitizing th s r cords and starts asking f r them 
from the synchr niz r, th y already hav the BJDatabase 

35 format. Ther fore, th synchronizer 15 does not n ed t 
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map them bef r s nding them to the B_Sanitizer module 12 
of th B_Translator 19. For the same r ason, th re is no 
need for them to be mapped once they are sent back by the 
B_Sanitizer after having been sanitized. Once all the 
5 records are loaded, the records will undergo the same 
orientation analysis that the B_Records underwent (Fig. 
11) . 

At this point, all records are loaded into the 
Workspace. SKGs are complete since every record at the 

10 time of loading is connected to the appropriate SKG. 

ClGs now contain all records that could be matched based 
on unique IDs. At this point, the records in the 
Workspace will be analyzed according to Conflict Analysis 
and Resolution ("CAAR") which is set out in Fig. 12 and 

15 in more detail in Figs. 13-18 and corresponding detailed 
description. 

First, in step 500, ID bearing fanned instances in 
the History File records are matched to the fanned 
instances in the ID bearing database from which they 

20 came* The records from the database which have remained 
unchanged are formed into a new FIG. A new Synthetic 
Master is created based on those records and joined to 
them. The records which have been changed or deleted 
since last synchronization are set free as single 

25 records. They also result in a new exclusion list being 
created based on an old exclusion list and these new 
single records. 

Second, in step 501, matches are sought for the ID 
based CIGs which are the only CIGs so far created in 

30 order to increase the membership of those CIGs. 

Preferably an exact all fields match is sought between 
current members of a CIG and a new one. Failing that, a 
weaker match is sought. 

Third, in step 502, master/ instanc s match is 

35 sought between r curring r cords and non-unique ID 
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bearing instances by trying to find the larg st group of 
instanc s which natch certain valu s in the Recurring 
Master. 

Fourth, in step 503, the items remaining in the 
5 SKGs are matched up based on either exact all field match 
or master/ instance match, or a weaker match. 

Fifth, in step 501, the appropriate CIGJTypes are 
set for all the CIGs. CIGJTypes will determine what the 
outcome of unloading the records will be. 
10 Referring to Fig. 13, first step in CAAR is 

analyzing unique ID bearing Fanned Instance Groups. This 
analysis attempts to optimize using unique IDs assigned 
by databases in analyzing fanned instances of recurring _ 
records. 

15 The analysis is performed for all Recurring 

Masters (i.e. all recurring records) which have ID- 
bearing fanned instances (or FIG records) in the H_File 
(step 550) . All FIG records in the History File 
associated with a Recurring Master are analyzed (steps 

20 551-559). They are all removed from the SKG. If a FIG 
record is a singleton CIG, it means that it was deleted 
from the database since the previous synchronization. 
Therefore, it is added to the New_Exclusion__List (step 
553). If a FIG record is a doubleton and is an exact 

25 match, it means that the record was not modified since 
the previous synchronization. In this case, the record 
from the database is also removed from SKG (step 555) . 
If a FIG record is a doubleton but is not an exact match 
for its counterpart in the database, it means that the 

30 record was changed in the database. The History File 
record is treated as a deletion and therefore added to 
the New_Exclusion_List. The modified record in the 
database, which does n t match th r curring rec rd any 
longer, is tr at d as a free standing record un- 

35 associated with th Recurring Mast r (step 557) . 
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Upon analysis of all FIG records, a new rec rd, 
the Synthetic Master, is creat d and join d in a CIG with 
the Recurring Master (step 231-236) . The Synthetic 
Master has the same characteristics as the Recurring 
5 Master, except that it has a new exclusion list which is 
a merger of the New_ExclusionJList and the Exclusion_List 
of the Recurring Master (step 563). Also a new FIG is 
created between the Synthetic Master and the CIG-mates of 
all FIG records from the History File (step 565) . 

10 In steps 567-569, the Synchronizer checks to see 

if there are some instances of the Recurring Master which 
fall within the previous synchronization's date range but 
fall outside of the current synchronization's date range. 
If so, the Fan_Out_Creep flag is set, indicating that the 

15 date range has moved in such a way as to require the 

record to be fanned for the database before unloading the 
record. The Fan__Out_Creep flag is an increase in the 
value in the Non_Key_Field Hash of the Recurring Master. 
In this way, the Recurring Master during the unloading of 

20 the records will appear as having been updated since the 
last synchronization and therefore will be fanned for the 
current date range* 

In step 570, all the FIG records analyzed or 
created in this analysis are marked as Dependent_FIGs . 

25 This results in these records being ignored in future 
analysis except when the recurring records to which they 
are attached are being analyzed. 

At the end of the above analysis, all the records 
having a unique ID assigned by their databases have been 

30 matched based on their unique ID. From this point 

onward, the records which do not have unique IDs must be 
matched to other records based on their field values. In 
the pr ferr d embodiment, th r ar two cat g ries f 
fi Id valu matches: strong matches and w ak matches. A 

35 strong match betwe n two records that hav matching key 
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fields is when non-k y fields of the two records match or 
it is a Recurring Master and a fanned instance match 
(Pig. 14, steps 606-610). Referring to Fig. 15, a weak 
match between two records that have matching key fields 
5 is when the following are true: each of the two records 
are from different origins, because two records from the 
same source should not be in a CIG (e.g., A_Database and 
History File) ; each is not a weak match for another 
record because there is no reason to prefer one weak 

10 match over another; each is not a Dependent_FIG since 
these records do not have an independant existence from 
their recurring masters; both records are either 
recurring or non-recurring since a recurring and a 
nonrecurring should not be matched except if one is an 

15 instance of the other in which case it is a strong match; 
and, in case of non-recurring, they have matching 
Key_Date_Field which is the same as the Start_Date in the 
preferred embodiment because items on the same date are 
more likely to be modified versions of one another. 

20 Referring to Fig. 14, these two types of matching 

are used to match records to, existing CIGs for History 
File records which have been created based on matching 
unique IDs. Only doubleton CIGs are looked at, because 
singleton CIGs are handled in step 504 of Fig. 12 and 

25 tripleton CIGs are complete (steps 601-604). If a strong 
match is found, then if the record was a weak match in 
another CIG, it is removed from that CIG, and new weak 
match is found for that CIG (612-614) . While weak 
matches are left in SKGs in case they will find a strong 

30 match, strong matches are removed from their SKGs (step 
614). If a strong match is not found, then a weak match 
is sought (steps 617-620) • All records in the CIG are 
remov d from SKG if no weak match is found, becaus this 
means that there is no possibility of ev n a weak match 

35 for this r cord (step 619) . 
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The next step in CAAR is finding non-unique ID 
bearing instances for recurring items (Fig. 12, step 
503). Referring to Fig. 16, this analysis takes place 
only if the database from which instances matching a 
5 recurring record are sought does not provide unique ID or 
if we are synchronizing from scratch (steps 650-653) • 
The goal of this analysis is to find matching instances 
for each Recurring Master from a different source than 
the Recurring Master. This analysis counts the number of 

10 records in SK6 of the Recurring Master which have 

matching Non_Date_Hash value (steps 665-669). The group 
of matching SKG records having the same non_Date_Hash 
value and having the highest number of members (if the 
number of members exceeds 30% of unexcluded instances) is 

15 then formed into a Homogeneous_lnstances_Group (steps 
670-672) . A Synthetic Master is created using the 
Rep_Basic of the Recurring Master and using the values 
from the homogeneous instances group. An Exclusion list 
is created based on the items belonging to the recurrence 

20 pattern but missing from the Homogeneous_Instances_Group. 
The Synthetic Master is added to the CIG of the Recurring 
Master (steps 673-678). A new FIG for the Synthetic 
Master is then created using the 

Homogeneous_Instances_Group (step 679) . These records 
25 are removed from any CIGs to which they belonged as weak 

matches and new weak matches are sought for those CIGs 

(steps 680-684) . Since the records in 

Homogeneous_Instances_Group have now been matched to a 

recurring record, they are marked as Dependent_FIGs (step 
30 683) . The Recurring Master's CIG is then marked with 

Fan_Out_Creep flag, if necessary (step 685). 

The next step in CAAR is completing analysis of 

rec rds in SKGs (Fig. 12, step 504). Referring to Fig. 

17, this analysis attempts to incr ase th populati n of 
35 CIGs up to a maximum by finding k y fi Id bas d matches 
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with records from a source different from those of th 
CIG records. This analysis is p rform d by analyzing all 
the records in the SKGs except for the singleton SKGs 
(steps 703 and 712). The first thing is to remove any 
5 members that have already been marked as WEAK matches 
attached to ID-based doubleton CIGs. Those are left in 
the SKG up to this point to allow for the possibility 
that a STRONG match would be found instead. But that is 
not possible any longer (steps 713-715) . Once the weak 

10 matches have been removed, all remaining SKG members 
belong to singleton CIGs. Any non-singleton CIGs which 
are formed from here on will be purely key field based. 

Throughout the remaining SKG Analysis we are 
careful not to seek H_Record-A_Record or H_Record- 

15 B_Record matches for unique ID-bearing Source, since that 
would violate the exclusively ID-based matching scheme 
that applies in such cases. Note however that an 
A Record-B_Record match is acceptable even if both 
A Database and B__Database are unique ID-bearing 

20 databases. 

Given that Key Field should not be performed where 
ID based matches are available (or otherwise there may be 
matches between records with differing IDs) , there are 
limits to how big CIGs can get at this point. If both A 

25 and B Databases are unique ID-bearing, any remaining 

H Record must remain in Singleton CIGs, because they are 
prohibited from forming key fields based matches with 
items from either databases. Such H_Records are simply 
removed from the SKG when they are encountered. If just 

30 one of the two databases being synchronized is unique ID- 
bearing then the maximum population that any CIG can now 
attain is 2 (Fig. 18, steps 750-751). If neither 
database is unique ID bearing th n the CIG_Max_Size is 
three. F r v ry CIG which is analyzed in Fig. 17, th 

35 CIG Max Size is set according to this logic. Wh n a CIG 
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reaches its maximum possibl population all of its 
memb rs are removed from th appropriate SKG. 

First, strong matches for the H-records are 
searched for, before trying to find A-B matches. If both 
5 Databases are non-unique ID-bearing then two strong 
matches for each H_Record, an H-A and an H-B match, are 
sought (steps 715-720) . If finding a strong match 
results in reaching the CIG_Max_Size, all members of the 
CIG are removed from the SKG (step 721) . 

10 When maximum CIG population is 3, weak matches are 

sought for strong matching CIG doubleton in order to 
build triplet CIGs. The first weakly matching SKG member 
is added to the CIG (steps 722-728) . Whether or not a 
weak match is found for any of the doubleton CIGs, its 

15 members are removed from the SKG (step 726). As there 
are no strong matches left in the SKG, weak matches are 
found for any remaining SKG members and joined to them in 
CIGs (steps 722-725) - 

At this stage, all CIGs are built . They must now 

20 be examined to determine what needs to be done to these 
records so that the databases are synchronized, i.e. 
whether the records in the CIGs need to be added, deleted 
or changed in the two databases. First step is 
determining the CIG_TYPE which represents the relation 

25 between the records. The following CIG types are 
defined, all using a 3 -digit number that represents 
values found for A_D AT ABASE, History File, and 
B_Database, respectively: 

1. 001 - record is "new* in the B_DATABASE 

30 2. 010 - record is present in History, but absent in 

both A_Database and B_Databases 

3. 100 - record is "new* in the AJDatabase 

4. 101 - record is "new* in both A_Database and 
B DATABASE; same in both 
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5. 102 - r cord is "new" in both A_Database and 
B_DATABASE; different in each (conflict) 

6. 110 - record deleted from B_DATABASE 

7. Oil - record deleted from A_Database 

5 8. 012 - record deleted from A_Database and changed 

on B_DATABASE (DEL VS CHANGE conflict) 
g. 210 - record changed on A_Dat abase and deleted 

from B_DATABASE ( DEL vs CHANGE conflict) 

10. Ill - record unchanged since previous 
10 synchronization 

11. 112 - record changed on B_DATABASE only since 
previous synchronization 

12. 211 - record changed on A_Database only since 
previous synchronization 

15 13. 212 - record changed identically on both since 
previous synchronization 

14. 213 - record changed differently on each since 
previous synchronization (conflict) 

15. 132 - a conflict (102 or 213) was resolved by 
20 forming a compromise value; Update both 

16. 13F - created when a 132 Update both CIG is Fanned 
into the BJ5ATABASE 

Fig. 19 shows the method used for setting all 
except the last two CIG_Types which are set in other 

25 operations. 

Four of the CIG types assigned above involve 
conflicts: 102, 213, 012, and 210. Conflicts are those 
instances where a specific conflict resolution rule 
chosen by the user or set by default, or the user's case 

30 by case decision, must be used to determine how the 

records from the databases should be synchronized. CIG 
types 012 and 210 are cases where a previously 
synchr niz d record is chang d on one sid and del ted on 
the other* In the preferr d mb diment, such conflicts 

35 are resolved acc rding t th rule that CHANGE overrules 
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the DELETE. So th net r suit for CIG type 012 Is to add 
a new record to the A_Database to match the record in the 
B_DATABASE. The reverse is true for CIG type 210, where 
a new record is added to the B_Dat abase. In an alternate 
5 embodiment, the user may be allowed to register an 

automatic preference for how to resolve such conflicts or 
decide on a case-by-case basis a conflict resolution 
option. 

The other two conflict types — 102 and 213 — are 
10 resolved in the preferred embodiment according to the 

Conflict Resolution Option established by the user. 

First, the user may choose to ignore the conflict. This 

option leaves all 102 and 213 conflicts unresolved. 

Every time synchronization is repeated the conflict will 
15 be detected again and ignored again, as long as this 

option remains in effect and as long as the conflicting 

records are not changed by other means. 

The user may choose to add a new record to each of 

the two databases. This option resolves 102 and 213 
20 conflicts by adding the new A_Record to the B_Dat abase, 

and adding the new BJRecord to the A_Dat abase. This 

option is implemented by breaking a 102 CIG into two 

separate CIGs (types 100 and 001) and a 213 CIG into 

three separate CIGs (types 100, 010, and 001) . 
25 Subsequent processing of those descendant CIGs causes new 

records to be added across and stored in the History 

File. 

The user may elect that A_Dat abase records should 
always trump or win over B_database records. This option 
30 is implemented by changing the CIG type to 211 - the 
processing during unloading the records changes the 
record value in the B_Database to match the current 
record value in the A — Database. 

The user may el ct that B_Databas records should 
35 always trump or win over B_databas records. This option 
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is implem nted by changing th CIG typ to 112 - the 
processing during unloading th records chang s th 
record value in the A_Database to match the current 
record value in the B_Database. 
5 The user may choose to be notified in case of any 

conflict. The user is notified via a dialog box 30, 
shown in Fig. 20, whenever a CIG type conflict of 102 or 
213 arises. The dialog box shows the record that is 
involved in the conflict 31. It also shows the 

10 A Database 32 and B_Database 33 values for all 

conflicting fields, in a tabular display, with Field 
Names appearing in the left column 34. A dropdown list 
(not shown) in the lower left hand corner of the dialog 
37, offers a total of three choices - add, ignore, and 

15 update. The use may choose to add new records or ignore 
the conflict. The user may also choose that the A_Record 
or B_ Record should be used to update the other record. 
The user may also decide to create a compromise record by 
choosing values of different fields and then choosing 

20 update option. In this case, the CIG type is changed to 
132, which results in an updating both databases with the 
new record compromise record. 

When the user has chosen to be notified in case of 
conflict, if the user chooses to ignore conflict or that 

25 either the record of the AJDatabase or the B_DATABASE 
should win, the CIG type is left as a conflict CIG type 
(102 or 213) and a separate Conflict Resolution Choice is 
stored in the FLAGS word associated with each CIG member. 

The final step in setting CIG_Types is the process 

30 for dealing with difficulties which arise from exclusion 
lists. For example, in a triple Recurring Master CIG, 
suppose the History File Recurring Master does not have 
any exclud d instances. Th A_R cord has the f llowing 
exclusion list: 

35 12/1/96, 12/8/96 
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Th B_Rec rd has th following xclusion list: 

1/1/97, l/8/97 f 1/15/97, 1/22/97, 1/29/97 
If comparison of the Recurring Masters includes 
comparing exclusion list Field Values, this set of 
5 changes would cause the Synchronizer to report a CIG type 
213 conflict. 

If the Conflict Resolution Option is set to 
A_Database record wins, then the outcome prescribed by 
the Synchronizer would be for the A_Database to keep its 

10 exclusion list as is and for the BJDatabase to make its 
exclusion list match that of the A_Database. 

The result would be to have a lot of duplicate 
entries in both Databases. The A_Database would have 
five duplicate entries in January 97 - that is the five 

15 unmodified Recurring Master instances, plus the five 
modified instances added across from B_Database to 
A_Database. The B_Database would have five duplicate 
entries in January 97, since synchronization has wiped 
out the five exclusions that were previously recorded in 

20 the BJDatabase exclusion list. 

Two steps are implemented for dealing with this 
problem. First, the COMPARE function does not take into 
account exclusion list differences when comparing 
recurring records. Second, referring to Fig. 21, any new 

25 exclusions added on to one recurring record will be added 
to the other record. The merging of exclusion lists is 
done regardless of any updates or conflicts, even 
unresolved conflicts, between the A_Database and 
B_Database copies of a Recurring Master. One exception 

30 is for CIG type 102 conflict which is left unresolved 
where Exclusion lists are not merged, because the user 
has chosen to leave those records as they are. 

In m st cas s wh r it is necessary to merge 
exclusion lists, the CIG typ s and/ or the Conflict 

35 Resolution Ch ice to arrang for all n cessary updates to 
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b performed during the unloading phases of 
synchronization. 

First, AJDatabase and B_Database records' 
exclusion lists are compared. In case of databases which 
5 do not permit recurring items, the exclusion list of the 
Synthetic Master is compared to the recurring record of 
the other database (step 852). If there is no 
difference, then nothing is done (step 853). If there 
are differences, then it is determined which exclusions 

10 appear only in one record. This comparison always yields 
one of the following scenarios: (1) all one-side-only 
Exclusions are on the AJDatabase (so Exclusions should be 
added to the B_Database) ; (2) all one-side-only 
Exclusions are on the B_Database (so Exclusions should be 

15 added to the A_Database) ; and (3) there are one-side-only 
Exclusions on both sides (so Exclusions should be added 
to both databases) . 

In each of these cases a separate table is used to 
look up instructions, for how to handle each specific 

20 situation (Figs 22-24) . The tables cover all possible 
combinations of previous CI6 types and outcome codes with 
all possible exclusion list changes (new and different 
exclusions added on A_Database, or on B_Dat abase, or on 
both sides) . Fig. 22 table is used in case of scenario 

25 1. Fig. 23 table is used in case of scenario 2. Fig. 24 
table is used in case of scenario 3 (Fig. 21 steps 854- 
856) . 

The analysis of records is now complete, and the 
records can be unloaded into their respective databases, 
30 including any additions, updates, or deletions. However, 
prior to doing so, the user is asked to confirm 
proceeding with unloading (Fig. 3, step 108-109). Up to 
this p int, n ith r of the databases nor th History File 
have been modified. The user may obtain through th 
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Translation Engine's User Interface various information 
regarding what will transpire upon unl ading. 

If the user chooses to proceed with 
synchronization and to unload, the records are then 
5 unloaded in order into the B_Database, the A_Database and 
the History File. The Unloader modules 6,10 of the 
Translators 5,9 perform the unloading for the databases. 
The Synchronizer creates the History File and unloads the 
records into it. The Control Module 2 of the Translation 
10 Engine 1 first instructs the BJTranslator to unload the 
records from Workspace into the B_Database. Referring to 
Fig. 25, for each CIG to be unloaded (determined in steps 
902-907), based on the CIGJTYPE and which database it is 
unloading into (i.e., A or B) , the unloader looks up in 
15 the table in Fig. 26 the outcome that must be achieved by 
unloading - that is, whether to update, delete, add, or 
skip (Leave_Alone) (step 908). In steps 909-913, the 
unloader enforces date range restriction for a database 
subject to date range. The user may select, or a 
20 selection may be made by default, whether to enforce the 
date range sternly or leniently. In case of stern 
enforcement, all records outside of the current date 
range would be deleted. This is useful for computers 
with small storage capacity. In case of lenient 
25 enforcement, the records are left untouched. 

Based on the result obtained from looking up the 
unloading outcome in the table, the unloader then either 
adds a new record (steps 920-926) , deletes an existing 
record (steps 914-919) , or updates an existing record 
30 (steps 927-933). It should be noted that because we only 
update those fields which need to be updated (step 928) , 
the fields which were sanitized but need not be updated 
are n t unloaded. Therefore, the values in those fi Ids 
remain in unsanitized form in the database. 
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Ref rring to step 914 , in some Applications when a 
Recurring Master must b added or updated, the r cord may 
have to be fanned out despite the ability of the 
Application to support recurring records. For example, 
5 the Scheduled- Translator is generally able to put almost 
any Recurring Master Item into Schedule* without fanning, 
but there are some exceptions. The Schedule* Translator 
uses one Schedule section to handle all appointments and 
events. For appointments, almost any recurrence pattern 

10 is allowed, but for events the only allowable true repeat 
type is YEARLY. DAILY recurring events can be dealt with 
by being translated into Schedule* multi-day events which 
are not recurring but extend over several days by setting 
the EndDate some time after the Start Date. But for the 

15 DAILY case there are restrictions. In particular 

exclusions in the midst of a multi-day Schedule* event 
cannot be created. So the Translator decides that if 
section type is ToDos or the item is a non-Event 
Appointment, then the record need not be fanned out. But 

20 if item is a YEARLY or DAILY with no exclusions then it 
can be stored as a Schedule* yearly or daily event. 
Otherwise, it must be fanned. 

Referring to Fig. 27, steps 950-984 set out the 
preferred embodiment of fanning recurring records that 

25 must be updated. All cases fall within three scenarios, 
shown in Fig. 29. 

In the first scenario a record which is a 
Recurring Master, and its counterpart in the other 
database is a Recurring Master, must be fanned now for 

30 its own database (steps 951-959) . If the CIG_TYPE of the 
record is 132 (i.e. update both records), then it is 
changed to 13F which is a special value specifically for 
this situation (step 951). For other CIG_Types, the CIG 
is brok n into thre singl ton and given CIG_Types 

35 signifying th ir singleton status. In both f these 
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cas s, th function Fanning_For_Add (steps 986-996, 
describ d b low) is called. 

In the second scenario, the record was fanned 
previously and is going to be fanned now also. First, 
5 the dates of the instances are recorded in a temporary 
date array (steps 961-963) • This array is compared to an 
array of the fanned instances of the recurrence pattern 
of the CIG Recurring Master from the other database 
(steps 965-966). The dates which are not in the array of 

10 fanned instance are marked for deletion (step 967) . The 
dates which are not in the temporary date array should be 
added to the unloading databases and therefore new FIG 
records are created for those dates (steps 968-973). The 
dates which appear in both arrays are compared to the 

15 Synthetic Master and marked accordingly for UPDATE or 
Leave_Alone (steps 974-978) . 

In the third scenario, the record which was 
previously fanned should now be fanned also. The 
opposing database's record in this scenario is also 

20 fanned instances. This is perhaps the most peculiar of 
the three cases. For example, a database may be able to 
handle multi-day (i.e. daily recurring) records but not 
any exclusion dates for such items. Such database may be 
synchronized with another database which fans all records 

25 in the following manner. A record representing a 7-day 
vacation in the Planner section of the database is fanned 
out to form 7 individual vacation days in the other 
database* One instance is deleted in the other database. 
Upon synchronizing the two databases, b/c the first 

30 databases does not does not provide for exclusion lists, 
the record must now be fanned. 

In this scenario, Master Records in a CIG are 
mark d as Garbage. Any FIG members attached to the 
H_Record, if any, are also marked as Garbage. All 

35 Instanc s found in the opposing database' s FIG ar truned 
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to singleton CIGs with CIG type 100 or 001 s that th y 
will be add d to the unloader's database wh n unloading 
is done. In this way the instances from one database is 
copied to the database providing for recurring records. 
5 Steps 985-995 describe the Fanning_For_Add 

Function which is used when outcome is to update or when 
the function is called by the Translator fanning for 
update. For each instance generated by fanning out the 
recurring record, a clone of the Recurring Master is 

10 created but excluding Rep_Basic and Rep_Excl field values 
and the unique ID field. All adjustable Date Fields 
(e.g. Start Date, End Date, and Alarm Date) are set and 
hash values for the new record is computed. The new 
record is then marked as Fanned_For_A or Fanned_For_B, as 

15 the case may be. This is then attached to the Recurring 
Master Item as a FIG member. 

Following unloading of the B_RECORDS, the Control 
Module 2 instructs the A_Translator to unload the 
A_Records from the Workspace (Fig. 3, step 111). This 

20 unloading is done in the same way as it was done by the 
B_Translator. In case of Rebuild_All Translators which 
have to reconstruct the database, all records which were 
loaded from the database but were not used in 
synchronization are appended and unloaded as the 

25 Translator builds a new database for its Application. 
The Control Module 3 next instructs the 
Synchronizer to create a new History File (step 112). 
Referring to Fig. 28, for every CIG in the Workspace, it 
is first determined which record should be unloaded to 

30 History File (steps 1001-1003) . In the next step, 
Excl_0nly flag is checked, which is set by the 
Merge_ExclusionJList logic (Fig. 21-24). If that flag is 
s t, a n w r cord for unloading is created which has all 
fields taken from the History File record, except that 

35 the newly m rged exclusion list is inserted into that 
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Hist ry File, all Flag Bits in th Extended Ind x are 
cleared except the bit that indicating whether or not 
this is a recurring item (step 1005) . The item is marked 
5 as a History File record to indicate its source. The 
CI6, FIG, and SKG are reset. All the HASH values and 
Start&EndDate&Time will be stored. All applicable unique 
ID are also stored (Steps 1006-1009). The current record 
is then stored in the new History File (step 1010) • If 

10 the current record is a Recurring Master for an ID- 
bearing FIG, we now store the whole FIG (i.e. all Fanned 
Instances) in the History File, with the FIG linkage 
words set in the History File to hold the FIG records 
together (step 1011) • Fanned instances which do not bear 

15 unique IDs are not stored in the History File since they 
can be re-generated by merely, fanning out the Recurring 
Master. 

Once all records are unloaded, various information 
necessary for identifying this History File and for the 
20 next synchronization are written into the History File 
(step 1013) . 

At this point Synchronization is complete. 
Applications, such as scheduling Applications, 
often have more than one database. Each of these 
25 databases are known as sections. Each of these sections 
contain different data and must be synchronized with 
their corresponding sections in other Applications. 
However, there is not necessarily a one to one 
relationship between sections of various Applications. 
30 For example, Application A may comprise of the following 
sections: Appointments, Holidays, Business Addresses, 
Personal Addresses, and ToDo. Application B however may 
comprise of the following s ctions: Appointments, 
Address s, ToDo-Tasks, and ToDo-Calls. Although th 
35 general character f the sections are the same, ther is 
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not a on to on relation b tv en the sections of thes 
two Applications: Appointments and Holidays in A contain 
the same type of data as Appointments in B; Business 
Addresses and Personal Addresses in A contain the same 
5 type of data as Addresses in B; and ToDo in A contains 
the same type of data as ToDo-Tasks and ToDo-Calls in B. 
Therefore, when synchronizing the sections of these two 
Applications, it is necessary to synchronize at least two 
sections of one Application with one section of another 

10 Application. 

The preferred embodiment performs this type of 
synchronization by providing for a number of section 
categories: Appointment, ToDo, Note, Address, and 
General Database. All sections of a particular 

15 Application are studied and categorized according to this 
categorization. Therefore, in the above example of 
Application A, Appointments and Holidays are categorized 
Appointment type sections (or database) , Business Address 
and Personal Address as Address type sections, and ToDo 

20 as a ToDo type section. 

For creating the map for mapping sections onto 
each other, an exact section match is always sought 
between sections of the two Applications. If not, one of 
the sections which were categorized as a section type is 

25 chosen to be the Main_Section among them. Other sections 
of the same type are referred to as subsections. All 
databases of the same type from the other Application 
will be mapped onto the Main_Section. 

To properly synchronize from one time to the next, 

30 it is necessary to keep track of the source of records in 
the Main_Section. In the preferred embodiment, if a 
record in the Main__Section of the A__Application does not 
come from th Main_S ction of the B_Application, n f 
fields in the record, pr f rably a text fi Id, is tagged 

35 with a unigu code id ntifying the subs ction which is 
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th sourc of the record. This is the record's Origin 
Tag. All r cords in th Workspace and the History Fil 
include a hidden internal field called _subType which 
contains the unique subsection code. Main_Section's 
5 field value in the preferred embodiment is zero so that 
it will not be tagged. When a record is loaded from a 
database into the Synchronization Workspace, the tag is 
stripped from the TagBearer field and put in the _subType 
field. If there is no tag, then the _subType is set to 

10 be the subType of the present section. If the TagBearer 
field is mapped then when reading records into the 
Workspace the tag, if any, is stripped from the TagBearer 
field value place it in ^subtype. 

Conversely when unloading records from the 

15 Workspace to a Database, the TagBearer field is tagged by 
a tag being added if the record is not from the 
Main_Section. 

Other embodiments are within the following claims. 



WO 98/24018 



PCT/US97/20660 



- 44 - 

What is claimed is: 

1* A computer implemented method of synchronizing 
at least a first and a second database, wherein the 
manner of storing a set of recurring date bearing 
5 instances differs between the first and second databases, 
and at least the first database uses a recurring record 
to store the set of recurring date bearing instances, the 
method comprising: 

processing a plurality of non-recurring records in 
10 the second database to generate a synthetic recurring 
record representing a set of recurring date bearing 
instances in the second database; 

performing a comparison of the synthetic recurring 
record of the second database to a recurring record of 
15 the first database; 

completing synchronization based on the outcome of 
the comparison* 

2. The method of claim 1 wherein the step of 
completing synchronization includes adding, modifying, or 

20 deleting one of the synthetic recurring record and 
recurring record* 

3. The method of claim 1 wherein, following the 
step of completing synchronization, one of the synthetic 
recurring record and recurring record is fanned back into 

25 a plurality of fanned non-recurring records* 

4* The method of claim 1 wherein the set of 
recurring date bearing instances is stored in the second 
database as a plurality of non-recurring records* 
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5. The method of claim 1 wh rein th set of 
recurring date bearing instances is stor d in the s cond 
database as a recurring record having a different record 
structure than the recurring record of the first 

5 database. 

6. The method of claim 1 further comprising 
storing a history file containing a record representative 
of one of the recurring record and synthetic recurring 
record in a past synchronization. 

10 7. The method of claim 1 wherein the synthetic 

recurring record has a list of excluded instances and the 
step of processing a plurality of non-recurring records 
in the second database to generate a synthetic recurring 
record further comprises generating a list of excluded 

15 instances representative of instances previously 
represented by the recurring record and currently 
represented by another record or deleted. 

8. The method of claim 1 wherein the recurring 
record and the synthetic recurring record each contain a 

20 list of excluded date bearing instances, wherein the step 
of performing a comparison of the synthetic recurring 
record to the recurring record includes performing a 
comparison of the list of excluded date bearing instances 
of the recurring record with the list of excluded date 

25 bearing instances of the synthetic recurring record. 

9. The method of claim 8 wherein the step of 
completing synchronization includes adding, modifying, or 
deleting the list of excluded date bearing instanc s of 
one f the recurring record and th synthetic recurring 

30 rec rd. 
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10. The method of claim 8 wh r in the step of 
completing synchronization includes adding, modifying, or 
deleting one of the synthetic recurring record and 
recurring record. 

5 11. The method of claim 8 wherein, following the 

step of completing synchronization, one of the synthetic 
recurring record and recurring record is fanned into a 
plurality of fanned non-recurring records excluding the 
instances in the list of excluded date bearing instances 
10 of a corresponding one of the synthetic recurring record 
and recurring record. 

12. The method of claim 6 wherein the second 
database assigns a unique ID to each record, and wherein 
the method further comprises: 
15 fanning one of the synthetic recurring record 

and the recurring record into a plurality of fanned non- 
recurring records; 

storing records in the history file 
representative of the plurality of fanned non-recurring 
20 records; 

storing in the history file the unique IDs 
assigned by the second database to the plurality of 
fanned non-recurring records; and 

recording linkages among the records 
25 representative of the plurality of non-recurring records 
and the record representative of one of the recurring 
record and synthetic recurring record. 
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13. The method of claim 6 wherein the second 
database assigns uniqu IDs to each r cord, the history 
file further contains records representative of non- 
recurring records of the second database from a past 

5 synchronization and unique IDs assigned to the non- 
recurring records of the second database, and the step of 
processing a plurality of non-recurring records in the 
second database to generate a synthetic recurring record 
further comprises: 

10 performing a comparison of the unique IDs stored 

in the history file with unique IDs of the plurality of 
non-recurring records in the second database; and 

selecting a set of non-recurring records in the 
second database based on the comparison of the unique IDs 

15 and generating the synthetic recurring record using the 
set of non-recurring records. 

14. The method of claim 13 wherein the step of 
selecting a set of non-recurring records further 
comprises selecting a set of non-recurring records in the 

20 second database having unique IDs matching a set of the 
unique IDs stored in the history file. 

15. The method of claim 13 wherein one of the 
synthetic recurring record and the recurring record has 
an exclusion list and the step of selecting the set of 

25 non-recurring records comprises: 

selecting a set of records in the history file 
having unique IDs failing to match any of the unique IDs 
of non-recurring records in the second database; and 

adding, modifying, or deleting the exclusion list 
30 of at least one of the synthetic recurring record and the 
recurring record, using the set of records in th history 
file. 
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16. Th m thod of claim 6 further comprises 

p rf onning a second comparison of one of the synthetic 
recurring record and the recurring record to the record 
representative of the recurring record or the synthetic 
5 recurring record in a past synchronization, and 

completing synchronization based on the outcome of the 
second comparison. 

17. The method of claim 1 wherein each recurring 
record and each non-recurring record includes a key 

10 field, and wherein the step of processing a plurality of 
non-recurring records in the second database to generate 
the synthetic recurring record further comprises: 

performing a second comparison of the key fields 
of the recurring and non-recurring records; and 

15 selecting a group of records from among the 

recurring and non-recurring records based on the outcome 
of the comparison. 

18. The method of claim 17 wherein the step of 
selecting a group of records comprises selecting the 

20 group based on identity of the content of the key fields 
of the recurring and non-recurring records. 
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19 . The m thod of claim 17 wherein each recurring 
r cord and each non-recurring record includes at least 
one other field, and wherein the step of processing a 
plurality of non-recurring records in the second database 

5 to generate a synthetic recurring record further 
comprises: 

performing a third comparison of the at least one 
other field of the non-recurring records in the group; 

selecting a set of non-recurring records based on 
10 the outcome of the third comparison; and 

generating the synthetic recurring record using 
the set of non-recurring records . 

20. The method of claim 19 wherein selecting the 
set of non-recurring records based on the outcome of the 

15 third comparison is based on identity of content of the 
at least one other field of the non-recurring records in 
the group. 
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21. A computer program, r si dent on a computer 
readable medium, for synchronizing at 1 ast a first and a 
second database, wherein the manner of storing a set of 
recurring date bearing instances differs between the 
5 first and second databases, and at least the first 
database uses a recurring record to store the set of 
recurring date bearing instances, comprising instructions 
for: 

processing a plurality of non-recurring records in 
10 the second database to generate a synthetic recurring 
record representing a set of recurring date bearing 
instances in the second database; 

performing a comparison of the synthetic recurring 
record of the second database to a recurring record of 
15 the first database; 

completing synchronization based on the outcome of 
the comparison. 



22. The computer program of claim 21 wherein the 
instruction for completing synchronization includes 

20 adding, modifying, or deleting one of the synthetic 
recurring record and [or the] recurring record. 

23. The computer program of claim 21 wherein, 
following the instruction for completing synchronization, 
one of the synthetic recurring record and recurring 

25 record is fanned back into a plurality of fanned non- 
recurring records. 

24. The computer program of claim 21 wherein the 
set of recurring date bearing instances is stored in the 
second database as a plurality of non-recurring r cords. 
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25. The computer program of claim 21 wherein th 
set f recurring date bearing instances is stored in the 
second database as a recurring record having a different 
record structure than the recurring record of the first 

5 database. 

26. The computer program of claim 21 further 
comprising instructions for storing a history file 
containing a record representative of one of the 
recurring record and synthetic recurring record in past 

10 synchronization. 

27. The computer program of claim 21 wherein the 
synthetic recurring record has a list of excluded 
instances and the instruction for processing a plurality 
of non-recurring records in the second database to 

15 generate a synthetic recurring record further comprises 
instructions for generating a list of excluded instances 
representative of instances previously represented by the 
recurring record and currently represented by another 
record or deleted. 

20 28. The computer program of claim 21 wherein the 

recurring record and the synthetic recurring record each 
contain a list of excluded date bearing instances, 
wherein the instruction for performing a comparison of 
the synthetic recurring record to the recurring record 

25 includes instructions for performing a comparison of the 
list of excluded date bearing instances of the recurring 
record with the list of excluded date bearing instances 
of the synthetic recurring record. 
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29. Th computer program of claim 28 vher in th 
instruction for completing synchronization includes 
instructions for adding, modifying, or deleting the list 
of excluded date bearing instances of one of the 

5 recurring record and the synthetic recurring record. 

30. The computer program of claim 28 wherein the 
instruction for completing synchronization includes 
instructions for adding, modifying, or deleting one of 
the synthetic recurring record and recurring record. 

10 31. The computer program of claim 28 wherein, 

following the instruction for completing synchronization, 
one of the synthetic recurring record and recurring 
record is fanned into a plurality of fanned non-recurring 
records excluding the instances in the list of excluded 

15 date bearing instances of a corresponding one of the 
synthetic recurring record and recurring record. 

32. The computer program of claim 26 wherein the 
second database assigns a unique ID to each record, and 
wherein the computer program comprises: 
20 fanning one of the synthetic recurring record 

and the recurring record into a plurality of fanned non- 
recurring records; 

storing records in the history file 
representative of the plurality of fanned non-recurring 
25 records; 

storing in the history file the unique IDs 
assigned by the second database to the plurality of 
fanned non-recurring records; and 

r cording linkages among the r cords 
30 r present at ive of th plurality of non-r curring records 
and th r cord representative of one of the recurring 
rec rd and synthetic r curring r cord. 
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33. The comput r program of claim 26 vh rein the 
s cond database assigns unique IDs to each r cord, th 
history file further contains records representative of 
non-recurring records of the second database from a past 

5 synchronization and unique IDs assigned to the non- 
recurring records of the second database, and the 
instruction for processing a plurality of non-recurring 
records in the second database to generate a synthetic 
recurring record further comprises instructions for : 

10 performing a comparison of the unique IDs stored 

in the history file with unique IDs of the plurality of 
non-recurring records in the second database; and 

selecting a set of non-recurring records in the 
second database based on the comparison of the unique IDs 

15 and generating the synthetic recurring record using the 
set of non-recurring records. 

34. The computer program of claim 27 wherein the 
instruction for selecting a set of non-recurring records 
further comprises instructions for selecting a set of 

20 non-recurring records in the second database having 

unique IDs matching a set of the unique IDs stored in the 
history file. 
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35. Th comput r program of claim 33 wherein one 
of th synthetic recurring record and the recurring 
record has an exclusion list and the instruction for 
selecting the set of non-recurring records comprises 

5 instructions for : 

selecting a set of records in the history file 
having unique IDs failing to match any of the unique IDs 
of non-recurring records in the second database; and 

adding, modifying, or deleting the exclusion list 
10 of at least one of the synthetic recurring record and the 
recurring record, using the set of records in the history 
file. 

36. The computer program of claim 26 further 
comprises instructions for performing a second comparison 

15 of one of the synthetic recurring record and the 

recurring record to the record representative of the 
recurring record or the synthetic recurring record in a 
past synchronization, and completing synchronization 
based on the outcome of the second comparison. 

20 37. The computer program of claim 21 wherein each 

recurring record and each non-recurring record includes a 
key field, and wherein the instruction for processing a 
plurality of non-recurring records in the second database 
to generate the synthetic recurring record further 

25 comprises instructions for: 

performing a second comparison of the key fields 
of the recurring and non-recurring records; and 

selecting a group of records from among the 
recurring and non-recurring records based on the outcome 

30 of th comparis n. 
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38. The comput r program of claim 37 wherein the 
instruction for selecting a group of records comprises 
instructions for selecting the group based on identity of 
the content of the key fields of the recurring and non- 

5 recurring records. 

39. The computer program of claim 38 wherein each 
recurring record and each non-recurring record includes 
at least one other field, and wherein the instruction for 
processing a plurality of non-recurring records in the 

10 second database to generate a synthetic recurring record 
further comprises instruction for: 

performing a third comparison of the at least one 
other field of the non-recurring records in the group; 

selecting a set of non-recurring records based on 
15 the outcome of the third comparison; and 

generating the synthetic recurring record using 
the set of non-recurring records. 

40. The computer program of claim 39 wherein 
selecting the set of non-recurring records based on the 

20 outcome of the third comparison is based on identity of 
content of the at least one other field of the non- 
recurring records in the group. 
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41. A computer program, resident on a computer 
readable medium, for synchronizing at least a first and a 
second database, wherein each record in the first and 
second databases includes a key field, comprising 

5 instructions for: 

performing a first comparison of the content of 
the key field of records of the first database with the 
content of the key field of records of the second 
database; 

10 selecting a plurality of groups of records of the 

first and second databases based on the outcome of the 

first comparison; 

performing a second comparison of records in one 

of the plurality of groups of records; and 
15 completing the synchronization based on the 

outcome of the second comparison. 

42. The computer program of claim 41, the 
computer program further comprises instructions for 
selecting the plurality of groups of records based on 

20 identity of the contents of the key fields of the records 
of the first and second database. 

43. The computer program of claim 41 wherein the 
instruction for completing synchronization further 
comprises instructions for selecting a 

25 corresponding item group of records based on the outcome 
of the second comparison wherein a corresponding item 
group of records comprises at least a record from one of 
the first and the second database. 
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44. Th c mputer program of claim 43 wh rein the 
instruction for completing synchronization further 
comprises instructions for: 

performing a third comparison of the records 
5 of the corresponding item group; and 

completing synchronization based on the third 

comparison. 

45. The computer program of claim 43 further 
comprising instructions for storing a history file 

10 containing history records representative of records of 
the first and second databases in a past synchronization 
and wherein a corresponding item group further comprises 
a history record. 

46. The computer program of claim 45 wherein the 
15 instruction for completing synchronization further 

comprises instructions for: 

performing a third comparison of the records 
of the corresponding item group; and 

completing synchronization based on the third 

20 comparison. 

47. The computer program of claim 46 wherein the 
key field is a date field. 



48. The computer program of claim 41 wherein the 
key field is a text field. 



WO 98/24018 



PCT/US97/20660 



- 58 - 

49. A computer implement d method of 
synchr nizing at 1 ast a first and a second databas , 
wherein each record in the first and second databases 
includes a key field, the method comprising: 

5 performing a first comparison of the content of 

the key field of records of the first database with the 
content of the key field of records of the second 
database; 

selecting a plurality of groups of records of the 
10 first and second databases based on the outcome of the 
first comparison; 

performing a second comparison of records in one 
of the plurality of groups of records; and 

completing the synchronization based on the 
15 outcome of the second comparison. 

50. The method of claim 49, the method further 
comprises selecting the plurality of groups of records 
based on identity of the contents of the key fields of 
the records of the first and second database* 

20 51. The method of claim 50 wherein the step of 

completing synchronization further comprises 
selecting a corresponding item group of records based on 
the outcome of the second comparison wherein a 
corresponding item group of records comprises at least a 

25 record from one of the first and the second database. 

52. The method of claim 51 wherein the step of 
completing synchronization further comprises: 

performing a third comparison of the records 
of the corr sponding item group; and 
30 completing synchronization based on the third 

comparis n. 
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53. Th method of claim 52 further comprising 
storing a history file containing history records 
representative of records of the first and second 
databases in a past synchronization and wherein a 

5 corresponding item group further comprises a history 
record. 

54. The method of claim 53 wherein the step of 
completing synchronization further comprises: 

performing a third comparison of the records 
10 of the corresponding item group; and 

completing synchronization based on the third 

comparison. 

55. The method of claim 49 wherein the key field 
is a date field. 

15 56. The method of claim 49 wherein the key field 

is a text field. 

57. A computer implemented method of 
synchronizing records of first and second databases, 
wherein at least one field of records of the first 
20 database is subject to a first rule of data value to 
which the corresponding field of records of the second 
database is not subject, the method comprising: 

comparing the content of the one field to the 
content of the corresponding field of the second database 
25 and in performing the comparison applying the first rule 
of data value; 

taking synchronization actions based on the 
outcom of the comparison. 
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58. The method of claim 57 wher in at least ne 
field of records of the second database is subject to a 
second rule of data value to which a corresponding field 
of records of the first database is not subject, wherein 
5 the method further comprises applying the second rule of 
data value in performing a comparison of the content of 
the corresponding field of records of the first database 
to the content of the at least one field of the second 
database. 

10 59. The method of claim 57 wherein applying the 

first rule of data value comprises: 

using the first rule of data value to modify a 

corresponding field of records representative of the 

records of the second database; and 
15 thereafter comparing the content of the modified 

corresponding field of the representative records to the 

content of the one field. 

60. The method of claim 57 wherein the content of 
the one field comprises at least a first portion and a 

20 second portion and the first rule of data value requires 
the presence of the second portion, and wherein applying 
the first rule of data value comprises comparing only the 
first portion to the content of the corresponding field. 

61. The method of claim 57 wherein the content of 
25 the corresponding field comprises at least a first 

portion and a second portion and the first rule of data 
value prohibits the content of the one field from 
containing the second portion and wherein applying the 
first rule f data value comprises comparing nly a first 
30 porti n of the content of th corresponding field to th 
one field. 
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62. The method of claim 57 wherein the first rule 
of data valu requires the content of the on field f 
the first database to have a specified value and wherein 
applying the first rule of data value comprises omitting 

5 comparison of the content of the one field with the 
content of the corresponding field. 

63. The method of claim 57 wherein the first rule 
of data value limits the content of the one field to a 
first specified value and wherein applying the first rule 

10 of data value comprises setting the first specified value 
equivalent to a second specified value of the content of 
the corresponding field. 

64* The method in claim 63 wherein the first 
specified value comprises a value selected from a range 
15 of values. 



65. The method in claim 63 wherein the second 
specified value comprises a value selected from a range 
of values. 

66. The method of claim 57 wherein applying the 
20 first rule of data value consists of one of: 

a) compearing only a portion of the content of the 
one field to the content of the corresponding field; 

b) comparing only a portion of the content of the 
corresponding field to the content of the one field; 

25 c) omitting comparison of the content of the one 

field with the content of the corresponding field; 

d) setting a first specified value of the one 
field quivalent to a second specified value of the 
corresponding field. 
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67. The method of claim 57 wherein the first rul 
of data value consists of one of: 

a requirement that the content of the one field be 
in upper case; 

5 a requirement that the content of the one field 

have a specified form of punctuation; 

a requirement that the content of the one field 
have a specified form of spacing; 

a requirement that the content of the one field 
10 have a value limited to a specified range of values; 

a requirement that the content of the one field 
have a first specified value based on the content of 
another field; 

a requirement that the content of the one field be 
15 limited to a specified length; and 

a requirement that the content of the one field 
include a specified code. 

68. A computer program, resident on a computer 
readable medium, for synchronizing records of first and 

20 second databases, wherein at least one field of records 
of the first database is subject to a first rule of data 
value to which the corresponding field of records of the 
second database is not subject, comprising instructions 
for: 

25 comparing the content of the one field to the 

content of the corresponding field of the second database 
and in performing the comparison applying the first rule 
of data value; 

taking synchronization actions based on the 

30 outcome of the comparison. 
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69. Th computer program of claim 68 wher in at 
1 ast one field of r cords of the sec nd databas is 
subject to a second rule of data value to which a 
corresponding field of records of the first database is 

5 not subject, wherein the computer program further 

comprises instructions for applying the second rule of 
data value in performing a comparison of the content of 
the corresponding field of records of the first database 
to the content of the at least one field of the second 
10 database. 

70. The computer program of claim 68 wherein 
applying the first rule of data value comprises: 

using the first rule of data value to modify a 
corresponding field of records representative of the 
15 records of the second database; and 

thereafter comparing the content of the modified 
corresponding field of the representative records to the 
content of the one field. 

71. The computer program of claim 68 wherein the 
20 content of the one field comprises at least a first 

portion and a second portion and the first rule of data 
value requires the presence of the second portion, and 
wherein applying the first rule of data value comprises 
comparing only the first portion to the content of the 
25 corresponding field. 
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72. The comput r program of claim 68 wherein the 
content of th c rresponding field compris s at least a 
first portion and a second portion and the first rule of 
data value prohibits the content of the one field from 

5 containing the second portion and wherein applying the 
first rule of data value comprises comparing only a first 
portion of the content of the corresponding field to the 
one field. 

73. The computer program of claim 68 wherein the 
10 first rule of data value requires the content of the one 

field of the first database to have a specified value and 
wherein applying the first rule of data value comprises 
omitting comparison of the content of the one field with 
the content of the corresponding field. 

15 74. The computer program of claim 69 wherein the 

first rule of data value limits the content of the one 
field to a first specified value and wherein applying the 
first rule of data value comprises setting the first 
specified value equivalent to a second specified value of 

20 the content of the corresponding field. 

75. The computer program of claim 74 wherein the 
first specified value comprises a value selected from a 
range of values. 

76. The computer program of claim 74 wherein the 
25 second specified value comprises a value selected from a 

range of values. 
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77. The computer pr gram of claim 68 wh r in 
applying th first rule f data value consists of one f : 

a) comparing only a portion of the content of the 
one field to the content of the corresponding field; 
5 b) comparing only a portion of the content of the 

corresponding field to the content of the one field; 

c) omitting comparison of the content of the one 
field with the content of the corresponding field; 

d) setting a first specified value of the one 
10 field equivalent to a second specified value of the 

corresponding field. 

78. The computer program of claim 68 wherein the 
first rule of data value consists of one of: 

a requirement that the content of the one field be 
15 in upper case; 

a requirement that the content of the one field 
have a specified form of punctuation; 

a requirement that the content of the one field 
have a specified form of spacing; 
20 a requirement that the content of the one field 

have a value limited to a specified range of values; 

a requirement that the content of the one field 
have a first specified value based on the content of 
another field; 

25 a requirement that the content of the one field be 

limited to a specified length; and 

a requirement that the content of the one field 
include a specified code* 
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79. A computer implemented meth d of 
synchronizing at least a first and a second database with 
a third database, the method comprising: 

selecting a first and a second set of records of 
5 the third database to be synchronized with records of a 
corresponding one of the first and second databases; and 

synchronizing the first and second sets of records 
with the corresponding one of the first and second 
databases . 

10 80. The method of claim 79, wherein the first set 

of records comprises records of the third database that 
were synchronized with records of the first database in a 
previous synchronization. 

81. The method of claim 80 further comprising, in 
15 the previous synchronization, tagging the records of the 
third database that were synchronized with the records of 
the first database with an origin identification code 
identifying the source of the records as the first 
database. 

20 82. The method of claim 81 whereirt the records of 

third database added in the previous synchronization are 
tagged with the origin identifying code. 

83. The method of claim 81 wherein the selecting 
step comprises selecting the records of the third 
25 database tagged with the origin identifying code as the 
first set of records. 



84. The m thod of 
step comprises selecting r 
not tagg d with the origin 
30 set of records. 



claim 81 wherein the selecting 
cords of the third database 
id ntifying c de as the sec nd 
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85. A comput r program, resident on a computer 
readabl medium , for synchronizing at least a first and a 
second database with a third database, comprising 
instructions for: 
5 selecting a first and a second set of records of 

the third database to be synchronized with records of a 
corresponding one of the first and second databases; and 

synchronizing the first and second sets of records 
with the corresponding one of the first and second 
10 databases. 



86. The computer program of claim 85, wherein the 
first set of records comprises records of the third 
database that were synchronized with records of the first 
database in a previous synchronization. 

15 87. The computer program of claim 86 further 

comprising instructions for, in the previous 
synchronization, tagging the records of the third 
database that were synchronized with the records of the 
first database with an origin identification code 

20 identifying the source of the records as the first 
database. 

88. The computer program of claim 87 wherein the 
records of third database added in the previous 
synchronization are tagged with the origin identifying 

25 code. 

89. The computer program of claim 87 wherein the 
selecting instruction comprises instruction for selecting 
the records of th third database tagg d with the origin 
identifying code as th first s t of r cords. 
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90. The computer program of claim 87 wherein th 
s 1 cting instructions comprises instructi n f r 
selecting records of the third database not tagged with 
the origin identifying code as the second set of records. 



5 91. A computer implemented method of 

synchronizing at least a first and a second database each 
containing dated records such as events, wherein the 
records of the first database extend across a narrow date 
range narrower than the date range of the records of the 
10 second database, the method comprising: 

performing a prior synchronization across a 
prior date range set using the date of the prior 
synchronization and the narrow date range; 

storing the prior date range and a history file 
15 containing information representative of the content of 
the databases following the prior synchronization; 

performing a current synchronization across a 
date range that combines the prior date range with a 
current date range set using the date of the current 
20 synchronization and the narrow date range. 

92. The method of claim 91 wherein the date of 
each record being synchronized is compared to a start and 
stop date of a date range to determine whether the record 
is in range. 
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93. A computer program, res id nt on a computer 
readable medium, for synchronizing at least a first and a 
second database each containing dated records such as 
events, wherein the records of the first database extend 

5 across a narrow date range narrower than the date range 
of the records of the second database, comprising 
instructions for: 

performing a prior synchronization across a 
prior date range set using the date of the prior 
10 synchronization and the narrow date range; 

storing the prior date range and a history file 
containing information representative of the content of 
the databases following the prior synchronization; 

performing a current synchronization across a 
15 date range that combines the prior date range with a 
current date range set using the date of the current 
synchronization and the narrow date range* 

94. The computer program of claim 93 wherein 
the date of each record being synchronized is compared to 

20 a start and stop date of a date range to determine 
whether the record is in range. 

95. A computer implemented method of 
synchronizing at least a first and a second database, 
each one containing date bearing records, the method 

25 comprising: 

identifying date bearing records of the first 

and second database that are within a narrow date range 

narrower than a date range of the records of one of the 

first and the second databases; and 
30 performing a current synchronization across the 

narr w date range by synchronizing th id ntifi d dat 

b aring records. 



WO 98/24018 



PCT/US97/20660 



- 70 - 

96. Th method of claim 95 wherein the st p of 
performing a current synchronization further comprises 
adding, modifying, or deleting records of the first 
database within the narrow date range. 

5 97. The method of claim 95 wherein the step of 

performing a current synchronization further includes 
deleting records of the first database that are outside 
of the narrow date range. 

98. The method of claim 95 wherein the narrow 
10 date range has a start date and a stop date and the date 
of a record being synchronized is compared to the start 
date and the stop date of the narrow date range to 
determine whether the record is within the narrow date 
range. 

15 99. The method of claim 98 wherein the date of 

a record being synchronized includes a record start date 
and a record stop date, the method further comprising: 
performing a comparison of the record start 
date to the stop date of the narrow date range and of the 

20 record stop date to the start date of the narrow date 
range; 

determining based on the comparison whether the 
record is within the narrow date range. 

100. The method of claim 95 wherein the first 
25 database contains a recurring record, the method further 
comprising fanning the recurring record within the narrow 
date range. 
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101. The method of claim 95 vh rein th first 
database contains a r curring record, furth r comprising: 

fanning the recurring record within a useful 
portion of the narrow date range, the useful portion 
5 being determined by application of a preference based on 
a current date of the current synchronization. 

102. The method of claim 101 wherein the 
preference includes a preference for future dates 
compared to the current date over past dates compared to 

10 the current date. 

103. The method of claim 101 wherein the 
preference includes a preference for dates closer to the 
current date over dates further from the current date. 



104. The method of claim 95 wherein a prior 

15 synchronization was performed across a prior narrow date 
range, such prior narrow date range being different from 
a current narrow date range of the current 
synchronization, wherein records representatives of the 
records of the first and second databases during the 

20 prior synchronization are stored in a history file, and 
wherein performing the current synchronization further 
comprises performing the synchronization using the 
history file and the prior narrow date range. 

105. The method of claim 104 wherein the narrow 
25 date range is a concatenation of the current narrow date 

range and the prior narrow date range stored in a history 
file during the prior synchronization. 
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106. Th m thod of claim 104 wher in th st p 
of perf rming a current synchronization further c xnprises 
adding, modifying, or deleting records of the first 
database that are within the current narrow date range. 

5 107. The method of claim 104 wherein the step 

of performing a current synchronization further includes 
deleting records of the first database that were present 
during a previous synchronization and that, following the 
current synchronization, are outside of the current 
Id narrow date range. 

108. The method of claim 104 wherein the step 
of performing a current synchronization further includes 
updating or deleting records of the first and second 
databases that are outside of the current narrow date 

15 range and within the narrow date range, based on the 
current synchronization. 

109. The method of claim 104 wherein the step 
of performing a current synchronization further 
comprises, based on a selection by a user, performing one 

20 of: 

(a) deleting the records of the first 
database that were present during a previous 
synchronization and that, following the current 
synchronization, are outside of the current narrow date 

25 range, and 

(b) updating or deleting records of the 
first and second databases that are outside of the 
current narrow date range and within the narrow date 
range, based on the current synchronization. 
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110* The meth d of claim 104 wherein one of 
the narrow date range # th prior narrow date range, and 
the current narrow date range includes a start date and a 
stop date and the date of a record being synchronized is 
5 compared to the start date and the stop date to determine 
whether the record is within a corresponding one of the 
narrow date range, the prior narrow date range, and the 
current narrow date range. 

111. The method of claim 110 wherein a record 
being synchronized includes a record start date and a 
record stop date, the method further comprising: 

performing a comparison of the record start 
date to the stop date of one of the narrow date range, 
the prior narrow date range, and the current narrow date 
range, and of the record stop date to the start date of 
the corresponding one of the narrow date range, the prior 
narrow date range, and the current narrow date range; and 
determining based on the comparison whether the 
record is within the corresponding one of the narrow date 
range, the prior narrow date range, and the current 
narrow date range. 

112. The method of claim 95 wherein the narrow 
date range comprises a relative narrow date range, the 
relative narrow date range being determined relative to a 

25 date of the current synchronization. 

113. The method of claim 104 wherein the 
current narrow date range comprises a relative narrow 
date range, the relative narrow date range being 
determin d relative to a date of the current 

30 synchr nization. 
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114. The method of claim 95 wh rein th first 
database contains a first plurality of non-r curring 
records representing a plurality of recurring date 
bearing instances, the method further comprising: 

5 generating a synthetic recurring record 

using the first plurality of non-recurring records; 

performing a synchronization of the 
synthetic recurring record with a record of the second 
database; 

10 if one of the record, the synthetic 

record, and a non-recurring record in the first plurality 
of non-recurring records is outside the narrow date 
range, fanning the synthetic record, or the record of the 
second database if it is a recurring record, into a 

15 second plurality of non-recurring records within the 
narrow date range. 

115. The method of claim 95 wherein the narrow 
date range comprises a concatenation of a first date 
range for the first database and a second date range for 

20 the second database. 

116. A computer program, resident on a computer 
readable medium, for synchronizing at least a first and a 
second database, each one containing date bearing 
records, comprising instructions for: 

25 identifying date bearing records of the first 

and second database that are within a narrow date range 
narrower than a date range of the records of one of the 
first and the second databases; and 

performing a current synchronization across the 

30 narrow date range by synchronizing the identified date 
bearing records. 
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117. The computer program of claim 116 wher in 
the instruction for performing a current synchronizati n 
further comprises instructions for adding, modifying, or 
deleting records of the first database within the narrow 

5 date range. 

118. The computer program of claim 116 wherein 
the instruction for performing a current synchronization 
further includes instructions for deleting records of the 
first database that are outside of the narrow date range. 

10 119. The computer program of claim 116 wherein 

the narrow date range has a start date and a stop date 
and the date of a record being synchronized is compared 
to the start date and the stop date of the narrow date 
range to determine whether the record is within the 

15 narrow date range. 

120. The computer program of claim 119 wherein 
the date of a record being synchronized includes a record 
start date and a record stop date, the computer program 
further comprises instructions for: 

performing a comparison of the record start 
date to the stop date of the narrow date range and of the 
record stop date to the start date of the narrow date 
range; 

determining based on the comparison whether the 
record is within the narrow date range. 

121. The computer program of claim 116 wherein 
the first database contains a recurring record, the 
computer pr gram further comprising instructions f r 
fanning the recurring record within the narrow dat 

30 rang . 
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122. The comput r program of claim 116 wher in 
the first database contains a recurring record, further 
comprising instructions for: 

fanning the recurring record within a useful 
5 portion of the narrow date range, the useful portion 
being determined by application of a preference based on 
a current date of the current synchronization. 

123. The computer program of claim 122 wherein 
the preference includes a preference for future dates 

10 compared to the current date over past dates compared to 
the current date. 

124. The computer program of claim 122 wherein 
the preference includes a preference for dates closer to 
the current date over dates further from the current 

15 date. 

125. The computer program of claim 116 wherein 
a prior synchronization was performed across a prior 
narrow date range, such prior narrow date range being 
different from a current narrow date range of the current 

20 synchronization, wherein records representatives of the 
records of the first and second databases during the 
prior synchronization are stored in a history file, and 
wherein performing the current synchronization further 
comprises instructions for performing the synchronization 

25 using the history file and the prior narrow date range. 

126. The computer program of claim 125 wherein 
the narrow date range is a concatenation of the current 
narrow date rang and the prior narrow date range st red 
in a hist ry fil during th pri r synchronization. 
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127. The comput r program of claim 125 wherein 
the instruction for performing a curr nt synchronization 
further comprises instructions for adding, modifying, or 
deleting records of the first database that are within 

5 the current narrow date range. 

128. The computer program of claim 125 wherein 
the instruction for performing a current synchronization 
further includes instructions for deleting records of the 
first database that were present during a previous 

10 synchronization and that, following the current 

synchronization, are outside of the current narrow date 
range. 

129. The computer program of claim 125 wherein 
the instruction for performing a current synchronization 

15 further includes instructions for updating or deleting 
records of the first and second databases that are 
outside of the current narrow date range and within the 
narrow date range, based on the current synchronization. 

130. The computer program of claim 125 wherein 
20 the instruction for performing a current synchronization 

further comprises instructions for, based on a selection 
by a user, performing one of: 

(a) deleting the records of the first 
database that were present during a previous 

25 synchronization and that, following the current 

synchronization, are outside of the current narrow date 
range, and 

(b) updating or deleting records of the 
first and second databas s that are utsid of the 

30 current narrow date range and within the narrow date 
range, based on the curr nt synchronization. 
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131. The computer program of claim 125 wherein 
on of the narrow dat range, the prior narrow date 
range, and the current narrow date range includes a start 
date and a stop date and the date of a record being 

5 synchronized is compared to the start date and the stop 
date to determine whether the record is within a 
corresponding one of the narrow date range, the prior 
narrow date range, and the current narrow date range. 

132. The computer program of claim 131 wherein 
10 a record being synchronized includes a record start date 

and a record stop date, the computer program further 

comprising instructions for: 

performing a comparison of the record start 

date to the stop date of one of the narrow date range, 
15 the prior narrow date range, and the current narrow date 

range, and of the record stop date to the start date of 

the corresponding one of the narrow date range, the prior 

narrow date range, and the current narrow date range; 

determining based on the comparison whether the 
20 record is within the corresponding one of the narrow date 

range, the prior narrow date range, and the current 

narrow date range. 

133. The computer program of claim 116 wherein 
the narrow date range comprises instructions for a 

25 relative narrow date range, the relative narrow date 

range being determined relative to a date of the current 
synchronization • 

134. The computer program of claim 125 wherein 
the curr nt narr w date range comprises instructions for 

30 a r lativ narr w date range, the relativ narrow date 
range b ing determined relativ t a date of the current 
synchr nization. 



WO 98/24018 



PCT7US97/20660 



- 79 - 

135. The comput r program of claim 116 wherein 
the first database contains a first plurality of n n- 
recurring records representing a plurality of recurring 
date bearing instances, the computer program further 

5 comprising instructions for: 

generating a synthetic recurring record 
using the first plurality of non-recurring records; 

performing a synchronization of the 
synthetic recurring record with a record of the second 
10 database; 

if one of the record , the synthetic 
record, and a non-recurring record in the first plurality 
of non-recurring records is outside the narrow date 
range, fanning the synthetic record, or the record of the 
15 second database if it is a recurring record, into a 
second plurality of non-recurring records within the 
narrow date range. 

136. The computer program of claim 116 wherein 
the narrow date range comprises instructions for a 

20 concatenation of a first date range for the first 

database and a second date range for the second database. 
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Pseudo Code for Generic A_Sanitization of B_DB Records in Workspace 

AJTranslator: 

350. REPEAT 



35 1 . FOR EVERY Field in an A_Record 

352. REQUEST Field from Synchronizer 

353. IF Last_Field, THEN EXIT LOOP 

354.. SANITIZE Field, according to A Sanitization rules 

355. END LOOP 

356. IF Last_Field, THEN EXIT LOOP 

357. SANITIZE Record according to A Sanitization rule 

358. FOR EVERY Field in an A_Record 

359. SEND Field value to Sanitizer 

360. END FOR 



361. UNTIL EXIT 

SYNCHRONIZER: 

In Response to Request for Field by A Sanitizer 
REPEAT UNTIL LAST RECORD 
READ B_Record 

MAP Record according to B_A Map 

REPEAT UNTIL AJTranslator Request a field from a new Record 
SEND REQUESTED BJield to A Translator 
WATT FOR RETURN of B_Field from A Translator 
STORE field Value in Mapping Cache 
END LOOP 

MAP record in Cache according to A-B Map 
STORE record in WORKSPACE 
END LOOP 

SEND LastJField flag in response to REQUEST 



375. 
376. 
377. 
378. 
379. 
380. 
381. 
382. 
383. 
384. 
385. 
386. 
387. 



FIG. 9 
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Conflict Resolution (Date Book) 



Item: 



Seminar Senes on Synchronization mult-day 



]Q£3EE| 



Field Name | 


Schedule + 7.0 | 


Piiot Organizer 


End Time 


4:30 PM 


3:30 PM 


Note 


In room 409 




Private 


Yes 


No 


First Date 


10/25/1996 


10/25/1996 



I Update 



m 



O Apply to ail conflict 



Update fields in both Schedule + 7.0 and Pilot Organizer 
using highlighted held values 



OK 



] I § tQ P I 



View 



] | Help | 



FIG. 20 



WO 98/24018 



PCT/US97/20660 



25/38 



2 

3 
| 
s 

1 
f 

do 



1 



O 
O 

Q 
2 
W 

O 

O 
O 

S 

o 

CO 



o 
u 



.1 

2 © 



S 



§ 

•J 
< 

8 



c 
o 

1 

K 

s i 

s uj 



•a 



.a 

•-■« 

•S 

H 

UJ 
CO 

D 
w 

X 
H 

en 

.5 

o 
a 



.5 

<u 

I 

H 

UJ 
CO 

D 

Z 
UJ 

X 
H 

< 

.3 

§ 



O U 
CQ P 

- ^ mm* 

u "S 

l o 

C o> 



o 
u 
u 

< 
.s 

o 



o 
u 
<u 
u 

DQ 

.s 

e 

o 



a 

E 
.5 

H 
UJ 

CO 

2 
UJ 

a 



o 
a 

Si 
-9 
JS 
.3 

a 
o 



o 
u 

.5 

• -I 

O -« J3 

& J2 ° 

00 OO w-^ 



5 ° 

3 * 

«2 O bo 

^ 8 •§ 

.2 >» 2 

•S o *o 

w * w 
* e 



u 

K 
UJ 



2 

_>> LU 



3 5 = 



s.u 



•a a) 



CO 

c 
O 



O. 



c 

i 



SJ= o 

O .e 

U * & 



UJ , UJ 
UJ U- UJ tt- UJ 



UJ 

22 



2 
u 

c 

C 
O 

u 



CM 

CD 



Q 
2 

UJ 



00 



00 00 



oo 



oo 



oo 



a. 

O 

3 

a 
z 

UJ 



WO 98/24018 



PCT/US97/20660 



26/38 



u 



3 U 
£ c 

H O — 

is 



5 o 
s u 

5 + 



o 



J 



o 



it 



« 

•9 

a g 

OS < 



u 

03 
Q 
< 

I 

u 



00 



CM 
O 



§ 

l.s 
3 i 

t* 

o S 

w 01 

•a £ 



8 



a -a 
< o 



60 
I 

is 



j 



CO 

I 
o 

I 

o 
a 

■3 

I 

S 

s 



£* < 



cn 

CM 



BO 



WO 98/24018 



PCT/US97/2O660 



27/38 



o 
U 

4 



J 
I 




So 
O 3 

o + 



.1 

s 

00 



8 



•s 

"EL 



o 



u 

•a 



3 

ca 



* a 

- w 

Ckf CQ 



CM 

cn 



«o 
o 

X 

(ti 
CQ 

a 

CO 

o 
U 



<N 



Q 

CQ 

i 

*5. 



O 

u 



i 

>» 

B .5 

a. o 
S3 



CM 



i 

o 



§ 
1 



w § 
13 

s8 

CO Wt 
to *S 

— -5 

uS Ji ~ 



8 o 



m 

CM 



04) 

co 

CM 



3 



1 

a 



■s 



O 

u 

la 

§.* 

ST Q 
a: cq 



CO 

■ 



3 

8 

CQ 
m 



i 



CO 
CM 

CD 

UL 



.¥ 

ca 
Q 

CQ 

s 

u 
O 



CQ 
Q 
< 



CO 

1 



WO 98/24018 



PCT/US97/20660 



28/38 



i 



o 

u 



o 



o 



£? 

CO 

3 



o 

8 



60 

.a 

i 

a j 
a. 5 

S K 

U ttJ 



u 

K 

w 
•a 

Sf 

o 



■5 



■e 

o 
o 

aa 

u 



o 
u 

CQ CO 

5 "J 
*> c 
> o 

I J 

a, id 

II 



u 
-5 

CO 



O 

o 

as 



0> 

5 



o 
u 

<d co 

•5 3 

'5 



s 2 

OJ .2 

CU ttJ 
« -a 

1*1 



Q. 



O 
u 
u 

te. 
«' 

<u 

■a 



O 
u 

CO 

■S J 

* § 
§1 

T x 

a, w 

<u -a 

s-| 



u 

X 
U4 

£? 

s 

I 

U 



-a 

s 

•s 

"3L 



o 
u 



.I s 

>» 
a, 
o 
u 

>» 

6 « 
a. o 

S O 



-a 

so 
w 

s 
•s 

V) 

3 



O 

u 

*. 

CQ 
b0 

.H 
>i 

CL 
O 

u 

a 5 

U CO 

u w 



o «§ 

a .2 .s 
~ e - 

2 3 = 
9 o ? 



"S3 CQ 

"3 o 



vg 



4> O 



4> O 

tO co CQ 

« 5 Q 



<o < 



O crj t3 

U d O 



I 

J 

w 

O 

y 

a: 



u 

CO 

e ' 
s 



60 



4> 



J 

"cL 
-a 

w 

O 

8 
3 

0Q 
•5 



o 
u 

ca co 

■s 3 

* o 

s-i 



4) 



-a 



m 



u 

-a 



o 



5+2 



CM 



CM 
CM 



bo 



CO 



CM 
O 



bp 
i 

m 

CM 



CM 



m 

CM 



WO 98/24018 



PCT/US97/20660 



29/38 



e 



So 



y ^ u 

a! u D K 2 



2 < H 
< CO 

o (2 o 
qQ w , 
u5 o p 



3 & 




as 8 o S S 8 3 8 o o o o 2 ^ s 2; 



WO 98/24018 



PCT/US97/20660 



30/38 



I 

s 
1 

4J 



o 

CO 

Si 



a? 

E 
I 

I 

oi 
O 




J 

w 

O 

2 u 

i'5i 

2 , = g 

.2 I 9 o 



in 

CM 

O 
ll 



o 



o a bo .5 

11 it 

§ w s -3 o 




88 



SIS! 



OO C\ 

8 8 



O ~ <N 

J? 2? 2? S3 

w 9\ C7\ 0\ 



WO 98/24018 PCT/US97/20660 



31/38 

// Original Current 

// Item Item Outcome 

{ 

•//— TIFCIG_001 - 1 (0) // item is present in BDB only 

B » B » oLEAVE_ALONE, // unloading to BDB 

B « B ' oKDD, // unloading to ADB 

B. B, oSAVE, // unloading to History File 

//-- CIGJ00 -1(1) // item is present in ADB only 

A_ A_ oADD. // unloading to BDB 

A_ A_ oLEAVE_ ALONE, .7 unloading to ADB 

A_ A_ oSAVE, // unloading to History File 

//— CIGJ01 - 1 (2) // item is identical in ADB and BDB 

B_ B_ oLEAVE_ALONE, // unloading to BDB 
A_ A_ oLEAVE~ ALONE, // unloading to ADB 
A_ B_ oSAVE, // unloading to History File 

//— CIGJQ2 - 1 (3) // NEW ADB ITEM < > NEW BDB ITEM 
// (the BDB WINS outcome is shown here) 

B_ B_ oLEAVE_ALONE, // unloading to BDB 
A_ B_ oUPDATE, // unloading to ADB 
A_ B_ oSAVE, // unloading to History File 

//— CIG_1 1) - 1 (4) // item is unchanged across the board 

B_ B_ oLEAVE_ALONE, // unloading to BDB 
A _ A_ oLEAVE_ALONE. // unloading to ADB 
H_ H_ oSAVE, // unloading to History File 

//— CIG_1 12 - 1 (5) // item CHANGED in BDB since last sync 

B_ B_ oLEAVE_ALONE, // unloading to BDB 
A_ B_ oUPDATE, // unloading to ADB 
H_ B_ oSAVE, // unloading to History File 

//— CIGJ 10 - 1 (6) // item DELETED from BDB since last sync 

H_ H_ oLEAVE_DELETED, // unloading to BDB 

A _ A _ oDELETE, // unloading to ADB 

H_ H_ oDISCARD, // unloading to History File 



//— CIG_21 1-1 (7) // item CHANGED in ADB since last sync 
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A_ A_ oLEAVEj\LONE, // unloading to ADB 
H_ A_ oSAVE, // unloading to History File 

//— CIG J12 - 1 (8) // item CHANGED IDENTICALLY in Src & BDB 

B_ B_ oLEAVE_ALONE, // unloading to BDB 
A_ A_ oLEAVE~ALONE, // unloading to ADB 
H_ A_ oSAVE, // unloading to History File 

//— CIGJ213 - 1 (9) // item CHANGED DIFFERENTLY in Src & BDB 
// (the BDB WINS outcome is shown here) 

B_ B_ oLEAVE_ALONE, // unloading to BDB 
A_ B_ oUPDATE, ,7 unloading to ADB 
H_ B_ oSAVE. // unloading to History File 

//— CIGJZ10 - I (10) // CHANGED in ADB, DELETED from BDB 

A_ A_ oADD, // unloading to BDB 

A" AT oLEAVE_ALONE, // unloading to ADB 

H_ A_ oSAVE. " // unloading to History File 

//— CIGJD11 - 1 (11) // item DELETED from ADB since last sync 

oDELETE, // unloading to BDB 
oLEAVE_DELETED, // unloading to ADB 
oDISCARD, // unloading to History File 

//— CIGJ)12 - I (12) // DELETED from ADB, CHANGED in BDB 

oLEAVE_ ALONE. // unloading to BDB 
oADD, // unloading to ADB 

oSAVE, // unloading to History File 



oLEAVE_DELETED, // unloading to BDB 
oLEAVEJDELETED, // unloading to ADB 
oDISCARD, // unloading to History File 



B 
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h" 


H_ 


H_ 


//— CIG 


_012- 


B 
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B~ 
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B~ 


//— CIG. 
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H_ 
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//— CIG. 


.132- 


B_ 
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H~ 
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H~ 


//— CIG_ 


13F- 
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a" 


h" 


a" 


H~ 



// to a "compromise" value stored in P-item 
// outcome is always UPDATE BOTH 

oUPDATE, // unloading to BDB 
©UPDATE, // unloading to ADB 
oSAVE, // unloading to History File 



// which has been Fanned To BDB 

oDELETE, // unloading to BDB 
oUPDATE, // unloading to ADB 
oSAVE // unloading to History File 
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// Note that we delete the recurring master on the BDB Side; 
// fanned instances take its place. 

}; 

™*™?J? l ™ S ab ° VC f0f CIG - 102 311(1 CIG - 213 "* oni * rc,evanl when Conflict Resolution Option is set to 
BOB WINS. If the Conflict Resolution Option is set to IGNORE or ADB WINS then those table entries are 
adjusted accordingly. For IGNORE we use the following table entries: 

//Original Current 

// Item Item Outcome 

//-- _CIGJTYPE_102 // NEW ADB ITEM < > NEW BDB ITEM 

B_ B_ oLEAVE_ALONE, // unloading to BDB 
A _ A _ oLEAVE_ALONE, // unloading to ADB 
B _ B _ oDISCARD, // unloading to History File 

//- _CIGJTPE_213 // item CHANGED DIFFERENTLY in Src & BDB 

B_ B_ oLEAVE_ALONE, // unloading to BDB 
A_ A_ oLEAVE_ALONE, // unloading to ADB 
H . H . oSAVE t // unloading to History File 

And for ADB WINS we use the following table entries: 

//Original Current 

// Item Item Outcome 

//- _CIG_TYPEJ02 // NEW ADB ITEM < > NEW BDB ITEM 

B_ A_ oUPDATE, // unloading to BDB 
A_ A_ oLEAVE_ALONE, // unloading to ADB 
B _ A_ oSAVE, // unloading to History File 

ll ~ .CIG_TYPE_213 // item CHANGED DIFFERENTLY in Src & BDB 

B _ A_ oUPDATE, // unloading to BDB 
A- A - oLEAVE_ALONE, // unloading to ADB 
H - A_ oSAVE, // unloading to History File 

When the NOY option is in effect, CIG-speciftc conflict outcomes are recorded in the CIG members' flag bits. 
When this is the case the following lookup table is used: 

static unsigned char TableAfterlLCR [JYNC OUTCOME COUNT] 

[AFTER JLCR CIG TYPE COUNT] 
[SYNC_UNLOAD PHASE "COUNT] 
[3] = * 

//Original Current 

//Item Item Outcome FIG 26C 
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// ; Entries for _OUTCOME_SYNC_BDB_WINS 

//— _CIG_TYPE_102 // NEW ADB ITEM < > NEW BDB ITEM 

B_ B_ oLEAVEjVLONE, // unloading to BDB 
A - B _ oUPDATE, // unloading to ADB 
A_ B_ oSAVE, // unloading to History File 

//— _CIG_TYPE_213 // item CHANGED DIFFERENTLY in Src & BDB 

B_ B_ oLEAVE_ALONE, // unloading to BDB 
A_ B_ oUPDATE, // unloading to ADB 
H_ B_ oSAVE, // unloading to History File 

// Entries for _OUTCOME_SYNC_ADB_WINS 

//— _CIG_TYPE_102 // NEW ADB ITEM < > NEW BDB ITEM 

B _ A_ oUPDATE. // unloading to BDB 
A_ A_ oLEAVE_ALONE, // unloading to ADB 
B_ A_ oSAVE, // unloading to History File 

//— _CIG_TYPE_213 // item CHANGED DIFFERENTLY in Src & BDB 

B_ A_ oUPDATE, // unloading to BDB 
A_ A_ oLEAVE_ALONE, // unloading to ADB 
H_ A_ oSAVE, // unloading to History File 

// Entries for IGNORE (LEAVE UNRESOLVED) 

//— _CIG_TYPE_102 // NEW ADB ITEM < > NEW BDB ITEM 

B_ B_ oLEAVE_ALONE, // unloading to BDB 
A_ A_ oLEAVE_ ALONE, // unloading to ADB 
B_ B_ oDKCARD, // unloading to History File 

//— _CIG_TYPE_213 // item CHANGED DIFFERENTLY in Src & BDB 

B_ B_ oLEAVE_ ALONE, // unloading to BDB 
A_ A_ oLEAVE_ALONE, // unloading to ADB 
H_ H_ oSAVE // unloading to History File 

1: "- TabteAteMR FIG. 26D 
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